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1. Executive Summary 

Small aircraft are expected to play an increasingly important role in the nation’s transportation system as 
very light jets (VLJ’s) make air-taxi operations cost competitive with automobiles for regional travel. The 
crew-cost per seat-mile is higher on small aircraft than larger transport aircraft and while initially 
planning to operate with two-pilot crews, it is likely that increased use of single -pilot operations will be 
desired in the future if safety and airspace integration concerns can be addressed. At the same time, 
widespread air-taxi operations are likely to generate increased interest in self-flown operations as people 
experience the productivity of small aircraft and see self-operation as a means to lower costs and increase 
flexibility. Fractional ownership and rental businesses could make piston and turboprop aircraft 
financially practical for travelers of modest means and VLJ’s retired from commercial, air-taxi operations 
are also likely to be financially attractive to private operators. Again, a significant concern is addressing 
safety and airspace integration issues stemming from increased, single-pilot operations, in this case for 
private pilots potentially having lower rates of exposure, a minimum of training and less formal oversight 
when compared to airline pilots. 

In response to these pressures, this paper reviews current and emerging operational experiences, 
technologies, and human-machine interaction theories to develop an integrated flight system concept 
designed to increase the safety, reliability, and performance of single-pilot operations in an increasingly 
accommodating but stringent national airspace system. This concept, known as the Naturalistic Flight 
Deck (NFD), uses a form of human-centered automation known as “complemation” (i.e., complementary- 
automation) to structure the relationship between the human operator and the aircraft as independent, 
collaborative agents having complimentary capabilities. The human provides commonsense knowledge, 
general intelligence, and creative thinking, while the machine contributes specialized intelligence and 
control, extreme vigilance, resistance to fatigue, and encyclopedic memory. In general, tasks are 
structured so that the human is involved in actions and decisions having significant consequences on the 
overall mission and safety and less involved in actions and decisions that are relatively deterministic, time 
constrained, tedious, repetitious or require great precision. 

To improve situation awareness and reduce the risk of mode confusion, tasks and their supporting 
interfaces are separated into two major partitions — the Actual and Notional systems. The pilot uses the 
Actual system to access information relevant to the immediate conduct and safety of flight (i.e., tactical 
information) and to control all functions that cause physical or external responses by the aircraft or its 
systems. The Notional System pertains to information and tasks used to support longer-range decision 
making (e.g., flight planning and in-flight strategic decision making) and development and maintenance 
of essential skills through review of previous flights and preview of planned or potential flights. The 
Notional system includes portable equipment facilitating use independent of a physical aircraft. 

The Actual and Notional system behaviors and interfaces are shaped by design metaphors selected to 
simplify initial training, operational ease of use, and reinforce the desired pilot and automation 
relationships. The Actual system uses the metaphor of a well-trained horse to support and interact with 
the pilot. The horse metaphor has two important aspects. First, the vehicle has a “horse-like” degree of 



situation awareness, intelligence, transportation capability, and autonomy. Second, the horse and rider 
communicate with each other through coordinated multi-modal interactions that include a strong haptic 
(sense of touch and proprioception) coupling between their respective “wills” (which will nearly always 
converge rapidly on a shared, safe and appropriate action). As implemented in a vehicle, this “H-mode” 
interface provides a bi-directional connection that is more natural and efficient than traditional visual 
display/keypad interfaces for real-time, spatial maneuvering tasks. In the NFD, the haptic link will be 
implemented through an active (i.e., force-feedback) side-stick and speed command lever. Like a rider of 
a horse, the pilot can direct the vehicle through a combination of more automated, “loose rein”, behaviors 
in which the vehicle has a relatively high degree of autonomy, and less automated, “tight rein”, behaviors 
in which the pilot more directly controls the flight path of the vehicle. Also like a horse, the vehicle will 
autonomously react to pop-up hazards while continuing to support the pilot’s near-term directives. The H- 
mode interface allows the pilot to “feel” the vehicle’s intentions/preferences in such situations and 
intuitively redirect it if desired or necessary (e.g., shifting the vehicle’s path around a conflict from a 
deviation to the left around to the right). Depending on the situation, the vehicle may readily adopt the 
pilot’s redirection; or if perceived as inappropriate, will provide a measured degree of resistance to ensure 
that the pilot recognizes the system’s reservations. Visual and auditory interface elements provide 
additional insight into the Actual systems status, perceptions, and future actions. 

The Notional system is based on the metaphor of an electronic assistant such as a crewmember or flight 
dispatcher. The goals of the Notional system are to help ensure that the pilot is appropriately prepared 
before a flight (e.g., has the requisite certifications, currency, suitable equipment, performs expected pre- 
flight checks, etc.), understands the risks/issues involved in a potential or active plan, and is primed to 
recognize and respond to changes that may require an update to the current plan. During a flight, the 
Notional system is constantly assessing progress relative to expectations and monitoring current and 
forecast conditions along the route to help ensure that safety margins are maintained, regulatory 
requirements are satisfied, and pilot specified preferences or constraints are met. Integrated mission- 
status-graphics are proposed to provide the pilot with regular feedback from these assessments and 
provide convenient access to more detailed information as desired or needed. 

To support the development of the NFD, an initial Concept of Operations (ConOps) has been created and 
selected normal and non-normal scenarios are presented in this document. These scenarios are used to 
illustrate key aspects of the human-machine interaction and the underlying roles and functional 
requirements of the human pilot and the airplane. The specific concepts outlined in these ConOps 
scenarios are initial baselines that will be refined or replaced as the overall system matures. A spiral 
development process using a range of realization fidelities including storyboards (e.g., ConOps 
scenarios), simulation prototyping, high-fidelity simulation, and flight development and evaluation will 
be required during this maturation process. During this process, it is vital to initiate and maintain a 
dialogue and partnership with potential pilots, commercializers (i.e., investors, manufacturers, marketers), 
and regulators to ensure that key opportunities, concerns, design guidelines and certification methods are 
addressed. This document is intended to be an initial element in this dialogue and feedback from the 
broader community is encouraged. 


2. Nomenclature 

ADS-B Automatic Dependent Surveillance Broadcast 

AOPA Aircraft Owners and Pilots Association 
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ATC 

Air Traffic Control 

ATIS 

Automatic Terminal Information Service 

ATP 

Airline Transport Pilot 

CFIT 

Controlled Flight Into Terrain 

CFR 

Code of Federal Regulations 

CAMA 

Crew Assistant for Military Aircraft 

ConOps 

Concept of Operations 

DAG-TM 

Distributed Air/Ground Traffic Management 

DCL 

Desired Configuration List 

FAA 

Federal Aviation Administration 

FMS 

Flight Management System 

GA 

General Aviation 

GPS 

Global Positioning System 

GPWS 

Ground Proximity Warning System 

H-coa 

H’s center of attention 

IAF 

Initial Approach Fix 

ITP 

Interactive Trip Planner 

IFR 

Instrument Flight Rules 

IMC 

Instrument Meteorological Conditions 

MEL 

Minimum Equipment List 

MSL 

Mean Sea Level 

NAS 

National Airspace System 

NEXRAD 

Next Generation Radar 

NFD 

Naturalistic Flight Deck 

NextGen 

Next Generation Air Traffic System 

NOTAM 

Notice To Airmen 

NTSB 

National Transportation Safety Board 

PIREP 

Pilot Report 

RJ 

Regional Jet 

RNP 

Required Navigation Performance 

RVSM 

Reduced Vertical Separation Minimums 

SCAS 

Stability and Control Augmentations System 

SVS 

Synthetic Vision System 

TAA 

Technically Advanced Aircraft 
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TCAS 

Traffic Collision Avoidance System 

VFR 

Visual Flight Rules 

VLJ 

Very Light Jet 

VMC 

Visual Meteorological Conditions 


3. Concept Goals and Objectives 


3.1. Goals: Improving Aviation Safety, National Airspace Capacity, and Mobility 


The trend over the past 10 years toward smaller passenger aircraft shown in figure 1 (Hansman, 2004) is 
likely to continue or accelerate in the coming decades. The use of smaller aircraft is likely to grow at a 



Figure 1 : Trend to smaller aircraft 


rapid pace as service providers strive to provide faster (e.g., direct flights) and more frequent service 
between a greater number of cities. Between 1998 and 2003, daily regional jet (RJ) operations increased 
by 356% (Mozdzanowska, 2004) and fractional ownership of business jets increased by 255%. As of 
January 2006 large scale, on-demand air taxi operations using very light jets (<6 passengers) are being 
planned by several companies such as POGO (www.flypogo.com) and Day Jet (www.dayjet.com). 

As airplanes get smaller, the cost of the crew becomes a larger percentage of the cost of a flight and a 
dominant factor in the ability to provide competitive services. Considering the “Very Light Jet” (VLJ) 
class of aircraft such as the Adam A700, Eclipse 500, and Cessna Mustang, the demand analysis of 
Dollyhigh (2002) suggests significant demand sensitivity to price. 

A key factor in growing beyond traditional markets for such aircraft is likely to be successfully operating 
with a minimal crew size. While present regulations (e.g., Part 91.1061 and Part 135.105) allow, with 
certain restrictions, carriage of passengers for compensation with only a single pilot, most of the current 
and planned services intend to use two pilots. This decision is probably influenced most significantly by 
customer acceptance and insurance costs. Customers for smaller airplanes may already be apprehensive 
about traveling in an aircraft significantly smaller than an RJ and the presence of a 2-pilot crew provides 
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an observable representation of airline-like safety. In addition, without some sort of credible back-up, 
customers are likely to view a single-pilot as a potentially catastrophic, single point of failure. Another 
important factor favoring the use of 2 pilots is the cost of insurance. While direct comparisons between 
the safety of single and two-pilot operations are difficult to make due to differences in the types of 
operations typically conducted, current accident statistics suggest that even with comparable equipage and 
pilot experience, crewed operations are 4-5 times safer than single-pilot operations (Collins, 2003). As 
would be expected, insurance companies take this difference into consideration when setting rates and it 
is often less expensive to hire a second pilot than to pay the additional insurance premium for single-pilot 
operations (Benenson, 2003). 

While the majority of early VLJ operations are likely to have 2-pilot crews for the above reasons, market 
forces are also likely to push to make single-pilot operations increasingly common if these disadvantages 
can be mitigated through other means such as improved technology. An opportunity exists to dramatically 
improve the safety and performance of single-pilot operations by considering the special needs of these 
operations and tailoring the design of the cockpit and supporting automation in light of available and 
emerging technologies and experience. Historically, there has been little difference between systems and 
automation designed for single -pilot and crewed aircraft, despite significant differences in the available 
human resources and ability of a crew to cross-check information, decisions, and actions. For example, 
there are no physical differences between the Cessna Citation I certified under Part 25 for crewed 
operations and the Citation I/SP certified under Part 23 for single -pilot operations. For single-pilot 
operations, the FAA requires an autopilot capable of flying coupled approaches, a squawk/ident switch on 
the yoke, and a boom microphone, items that were standard on both versions of the airplane. This lack of 
attention to the differing requirements and resources of single-pilot operations was perhaps the only 
practical approach prior to the advent of modem, digital systems. But, with the replacement of 
conventional, electromechanical systems with more capable digital systems, designing the cockpit and 
underlying automation specifically for such operations may dramatically improve the safety and 
performance of single-pilot operations. Furthermore, as the National Airspace System (NAS) continues to 
evolve, operations wanting to take advantage of the maximum efficiency and flexibility offered by the 
system will probably need to support reduced spacing initiatives (e.g., RVSM) and aircraft-based 
responsibility for traffic separation. These emerging requirements will further increase the challenges of 
safe and efficient single-pilot operations. 

Recognizing this opportunity, this document outlines a concept for integrating current and emerging 
technologies into an integrated system specifically designed to support future single-pilot operations in 
small aircraft. The range of aircraft and operations considered in this document are aircraft certified under 
CFR 14 Part 23, classes I, II, and III (e.g., non-commuter category airplanes, < 12,500 lbs takeoff 
weight); having category A or B approach speeds (i.e. , < 120 knots); and operated under Part 91 (private 
and fractional ownership programs) or on-demand operations under Part 135 with 9 or fewer passenger 
seats. While many of the concepts are applicable, in whole or part, to larger aircraft or two-pilot 
operations, the above vehicle classes and operations are considered the focus applications during 
discussion of the integrated design concept and applicable certification issues. Also, while the initial 
impetus and early adopters of the concepts discussed in this report are likely to be commercial operators 
that can gain economic benefits with minimal changes to existing regulatory statues and policies, it is 
desired that these same concepts can, with sufficient operational experience and maturation, form the 
basis for creating a new pilot rating (or alternatively a limited rating such as that issued for center-line 
thrust twins, for example) for pilots of appropriately equipped aircraft. Such a rating would consider the 
changed role and tasks of the pilot given the support of specified equipage and vehicle capabilities. The 
skill, knowledge, licensing, and currency requirements could thus be tailored for this new role with the 
goal of enabling safer, more capable pilots and operations with reduced formal instruction than nominally 
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required for similar operations today. A long-term measure of success in this regard would be enabling 
persons of average ability and motivation and with a volume of training roughly equivalent to earning a 
private pilot certificate restricted to VFR operations today (~60 hours of flight training + ground school), 
to operate an appropriately equipped aircraft in IMC with a level of safety, mission reliability, and 
workload comparable to similar trips made by automobile. 

3.2. System Objectives: Enable Single-Pilot Aircraft Operations 

The overall system objectives are to enable single-pilot operations with safety and performance 
comparable to Part 121 operations. With this motivation in mind, the following high-level objectives must 
be supported by any viable system concept that seeks to address future single-pilot, small aircraft 
operations. 

3.2.1. Safety consistent with broad public and institutional acceptance 

■ Objective: On a per trip basis, the risk of a serious or fatal injury should be less than comparable 
travel by automobile and ideally comparable to commercial air carrier. 

■ Rationale: Individuals and businesses often hesitate to utilize small aircraft due to both the perception 
of reduced safety and the reality that for many types of operations, the safety of small aircraft is less 
than that of other forms of transportation such as automobile or commercial airline (Guohua & Baker, 
2007; Bureau of Transportation Statistics, 2007). A level of safety comparable to these other forms of 
transportation must be achieved and maintained if travel by small aircraft is to be a viable alternative 
for most people. Furthermore, this objective should be achieved for all classes of pilot certification 
and experience, not just highly experienced, commercial or ATP rated pilots. Achieving high levels of 
safety for all classes of pilot, including relatively inexperienced pilots in single pilot operations, is 
important to manage the public’s overall perception of small aircraft safety and to ensure system 
robustness across a wide variety of pilots. 

3.2.2. Compatible with Current and Likely Future Airspace Environments: 

■ Objective: The system concept must support single-pilot operations in current and likely future air 
space system concepts of operation including Required Navigation Performance (RNP) based 
navigation, forms of distributed air-ground traffic management with various levels of self-separation 
responsibilities, and emerging security considerations. 

■ Rationale: It is currently predicted that significant changes to the national airspace system are likely 
to occur over the next two decades. While these concepts are not yet firmly defined, general 
requirements on the vehicle segment of the NAS can be foreseen and incorporated into the system 
concept. Such requirements are likely to include reduced separation and self-separation during certain 
mission phases and procedures and operating in airspace in which 4-D RNP concepts are used to 
define navigation performance and containment. That said, the pace of evolution of the other portions 
of the NAS is unpredictable so it is important that the flight system concept not depend on the 
introduction of new technologies not already being implemented in other segments of the NAS. 

3.2.3. Compatible with the Intent of Certification Regulations 

■ Objective: While not necessarily compliant with the letter of current regulations, the system concept 
must recognize the importance of certification and the need to design functions vital to safety and 
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mission conduct such that credible methods exist or can be developed to verify the performance of 
these functions with the necessary degree of confidence. 

■ Rationale: To be relevant, concepts must be certifiable. However, this requirement should not be in 
the sense of strict compliance with current regulations. Rather it should be done through application 
of a comprehensive system-safety analysis that considers the faults of both technology and human 
elements and achieves an equivalent or better level of safety than achieved with present practices. A 
key issue will be the appropriate integrity of aircraft systems that augment or perform tasks currently 
performed by the pilot and are critical to continued safe flight and landing. Traditionally, the pilot is 
relied upon to perform the vast majority of tasks critical to safety of flight as this avoids the burden of 
certifying such systems and the liability if there is a suspected failure. For example, in most small 
airplanes today, the pilot is relied upon to cross-check the basic flight instruments to detect and isolate 
failures of the pitot-static and gyroscopic instruments. Multiple accidents a year are typically 
attributed to failures to adequately perform this task. An automated system could perform this task in 
place of the pilot with much higher reliability, but such a system currently has to satisfy the flight- 
critical certification requirements of 23.1309 as a system failure could be catastrophic. Meeting these 
requirements could be extremely costly. From a system-safety perspective, having automation 
reliability one or two orders of magnitude greater than human performance for the same task would 
provide an overall safety benefit, despite not meeting the current requirement. In addition, having 
automation perform this constant, visually intensive monitoring task would allow the pilot to allocate 
their limited sensory and cognitive resources to other tasks for which they are better suited, further 
improving safety beyond the direct comparison of performance on this isolated monitoring task. 

3.2.4. Trip reliability comparable to commercial airlines 

■ Objective: In addition to providing a high level of safety, the system concept must be consistent with 
providing trip reliability comparable to commercial air travel. 

■ Rationale: Travelers need to be able to rely on completing flights such that the underling purposes of 
the trips are not significantly impacted. Table 1 indicates that commercial flights are delayed more 
than 15 minutes approximately 22% percent of the time and cancelled 2.4% of the time. Given that 
the hub and spoke system requires the typical traveler to make two flights between that true origin 
and destination suggests that the probability of having one of the legs delayed is 39% while the risk of 
at least one leg being cancelled is 4.7%. While cancellation of a leg is likely to impact the trip 
significantly (e.g., causing an unplanned overnight stay or inability to make a mid-day meeting), the 
impact of a delay is less certain depending on whether it results in a missed connecting flight. In the 
absence of objective data on this subject, it is estimated based on anecdotal experience that 20% 
percent of these delays cause a significant impact on the trip, defined as arriving at the final 
destination later than 2 hours after the planned arrival. Together, these significant delays and outright 
cancellations result in less than 90% probability of completing a trip as planned using commercial air 
transportation. 
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Year 

On time 
Arrivals 

On time 
(%) 

Arrival 

Delays 

Delayed 

(%) 

Flights 

Cancelled 

Cancelled 

(%) 

Diverted 

Flight 

Operations 

1997 

4,218,165 

77.94% 

1,083,834 

20.03% 

97,763 

1.81% 

12,081 

5,411,843 

1998 

4,156,980 

77.20% 

1,070,071 

19.87% 

144,509 

2.68% 

13,161 

5,384,721 

1999 

4,207,293 

76.11% 

1,152,725 

20.85% 

154,311 

2.79% 

13,555 

5,527,884 

2000 

4,125,263 

72.59% 

1,356,040 

23.86% 

187,490 

3.30% 

14,254 

5,683,047 

2001 

4,619,234 

77.40% 

1,104,439 

18.51% 

231,198 

3.87% 

12,909 

5,967,780 

2002 

4,329,635 

82.14% 

868,225 

16.47% 

65,143 

1.24% 

8,356 

5,271,359 

2003 

5,317,886 

81.96% 

1,057,804 

16.30% 

101,469 

1.56% 

11,381 

6,488,540 

2004 

5,566,323 

78.08% 

1,421,406 

19.94% 

127,757 

1.79% 

13,784 

7,129,270 


Note: For purposes of this report, a flight is considered delayed if it arrived at (or departed) 
the gate 15 minutes or more after the scheduled arrival (departure) time as reflected in the 
Computerized Reservation System. 

Table 1: Schedule Performance for Commercial Airlines 

3.2.5. Effective use of Technology 

■ Objective: The technology employed in the system concept cannot be less cost-effective than 
operating with a second pilot. 

■ Rationale: The goal of the overall activity is to achieve the benefits of single-pilot operations while 
improving the safety and performance of such operations in an increasingly demanding airspace 
environment. As such, if a proposed system concept were less cost effective than simply operating 
with 2 pilots, this concept would not be viable. For comparison purposes, from secure.salary.com, the 
co-pilot of a small (<12,5001bs), non-jet airplane earns a median salary of $52,000 per year. 
Assuming benefits and payroll taxes are 30% of direct salary expenses, and $10,000 annually for 
recurrent training, the annual cost of a co-pilot is $78,000 per year, or assuming 1000 flying hours per 
year, $78 per hour. Components of life-cycle, system cost include initial development, certification, 
component costs, maintenance, initial and recurrent pilot training, crew cost, passenger/cargo 
capacity, and operational impacts of missions not completed due to lack of capability or system 
failures. Since performing a rigorous analysis of life-cycle cost of as yet developed technology is not 
possible, this objective will be applied in a more qualitative sense. Also, greater emphasis will be 
placed on recurring costs than nonrecurring development costs since much of the development costs 
will be covered under this program. 

4. Overview of Current System Performance 

For complex, safety-critical systems such as the civil air transportation system, current system operations 
and performance should be used as a benchmark for proposed improvements. This section provides a 
brief overview of current and emerging small aircraft operations and technologies, highlighting areas of 
particular relevance to the objectives described earlier. Small aircraft are currently benefiting from an 
influx of new technologies similar to those introduced in the “glass flight deck” in commercial aircraft in 
the mid 1980’s. Because of the significant technological differences between airplanes that make up the 
majority of GA aircraft and the minority of GA aircraft that have state of the art avionics, this section is 
divided into two subsections. Section 4.1 deals primarily with experiences of the more common GA 
aircraft while section 4.2 deals with the current and emerging state of the art. 



4.1. State of the Practice 


The operational safety record of small aircraft is regularly summarized and analyzed by the National 
Transportation Safety Board (NTSB) and, for general aviation operations, the Aircraft Owners and Pilots 
Association (AOPA). Interested readers can download annual reports from these organization’s websites. 
While accident rates have trended downward over the past several decades, their primary and contributing 
causes have tended to remain the same and are very similar to commercial Part 121 operations, suggesting 
that strong, underlying factors are present. Table 2 (NTSB, 2004) indicates the ten most common 
occurrence chains for fatal GA accidents in the year 2000 while figure 2 (Boeing, 2004) indicates the 
primary types of fatal accidents for worldwide operation of commercial transports between 1994 and 
2003. Loss of control and CFIT are by far the primary causes of fatalities in both domains. Figures 3a and 
b (AOPA 2003; Boeing, 2004) show accident and fatality occurrences as a function of phase of flight, 
again showing similarities between GA and commercial operations. “Maneuvering flight” is largely 
unique to GA operations and includes activities such as practicing emergency procedures at low altitudes. 
Flight crew actions are identified as the top causal element in both large and small aircraft as shown in 
figures 4a and b (NTSB, 2004; Boeing, 2004). Taking a more detailed look at accidents attributed to 
human error, Weigmann and Shappell performed an analysis of commercial (Parts 121 and 135) (2001) 
and GA (2005) operations using a “human factors analysis and classification system” found that skill- 
based errors are the most common type of human error in both domains as shown in figure 5, with other 
error types such as decision errors and violations (e.g., going below minimums) playing important but 
lesser roles. Skill-based actions are actions performed without significant conscious thought such as stick 
and rudder manipulation or visual scanning. They often rely on practiced behaviors and are susceptible to 
attention or memory failures. 


Rank 

Chain Of Occurrences - 

Number of 

Fatal GA Accidents, 2000 

Accidents 

1 

Loss of Control In-flight -> ln-flight Collision with 
Terrain, Water 

95 

2 

In-flight Collision with TerrairVWater 

47 

3 

In-flight Collision with Object 

25 

4 

In-flight Collision with Object-. In-flight Collision 
with Terrain Water 

17 

5 

In-flight Encounter with Weather -> In-flight Collision 
with TerrainWater 

15 

6 

Airframe/Component/System Failure/Malfunction -» 
In-flight Collision with TerrairVWater 

9 

7 

In-flight Encounter with Weather -» Loss of 
Control In-flight -+ In-flight Collision with TerrainWater 

8 

8 

In-flight Encounter with Weather -> In-flight 
Collision with Object 

7 

9 

Loss of Control In-flight -> In-flight Collision with Object 

7 

10 

Airframe/Component/System Failure/Malfunction -> Loss of 


Control In-flight -> In-flight Collision with TerrairVWater 

6 


Table 2: Ten most common occurrence chains fatal GA accidents 
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Fatalities by Accident Category 

Fatal Accidents - Worldwide Commercial Jet Fleet - 1994 Through 2003 



flight explosion 


Number 

of fatal 32 24 2 2 2 1 2 16 3 

accidents 

105 total Note: Accidents involving multiple, non-onboard fatalities are included 
Accidents involving single, non-onboard fatalities are excluded 
Fatalities/accidents are placed in one category only. 


18 3 12 

* CFIT = Controlled Flight Into Terrain 
** RTO = Refused Takeoff 


Figure 2: Primary types of fatal accidents for worldwide operation of commercial transports 
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EMERGENCY PHASE OF FLIGHT 



Figure 3a: Accident and fatality occurrences as a function of phase of flight 
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Accidents and Onboard Fatalities by Phase of Flight 

Hull Loss and/or Fatal Accidents - Worldwide Commercial Jet Fleet - 1994 - 2003 
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Figure 3b: Accident and fatality occurrences as a function of phase of flight 


Total Broad Causes/Factors 
for On-Demand Part 135 Accidents, 1991-2000 
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Figure 4a: Causal factors in aviation accidents 
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Accidents by Primary Cause* 

Hull Loss - Worldwide Commercial Jet Fleet - 1994 through 2003 
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Airplane 

19 


Misc./Other 

7 
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Maintenance 
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■« 

Total with 
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’As determined by the investigating authority. 

Total 

186 

percent of accidents with known causes. 


Figure 4b: Causal factors in aviation accidents 



Year 

Figure 5: Contribution of human error types to accidents 

Some general observations that can be drawn from these studies are that accidents tend to occur during 
phases of flight involving a high number of critical and/or complex tasks. Task criticality is usually 
increased with proximity to terrain and obstacles in that the time available to detect and recover from an 
error is reduced. Critical tasks are not necessarily difficult to perform but are often unforgiving and a 
momentary lapse in a task such as poor speed control resulting in a low altitude stall/spin may be 
disastrous. Other types of errors such as decision errors are important, but can often be corrected before 
an accident occurs. Since the flight crew currently has responsibility for performing the vast majority of 
critical tasks, it is not surprising that human error is found to be the top causal factor of accidents. A more 
constructive observation would be that critical tasks, whether performed by humans or the machine, need 
to be designed for fault tolerance. This is already a requirement for the vehicle’s systems; per Advisory 
Circular, 23.1309-lc, at the vehicle level, no single failure can result in a catastrophic failure condition. 
This same philosophy must be extended to include the pilot as part of the pilot-vehicle system if 
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significantly higher levels of safety are to be achieved. 


The studies/reports referenced thus far are not specific to single -pilot operations and represent a mix of 
single-pilot and crewed operations. Studies of single -pilot incidents and accidents (e.g., Bergeron, 1980 
and Forsyth, 1978) have found generally similar types of accidents and relative importance of causal 
factors. As would be expected, the generally higher workload and vulnerability to human blunders are 
identified as sources of increased risk for single-pilot operations. 

In addition to strategies for improving safety, current operations provide insight into necessary 
capabilities for achieving or exceeding airline like mission reliability. In a survey of current general 
aviation pilots by Downen and Hansman (2002), weather and its impact on trip reliability was the number 
one factor cited in choosing other modes of transportation over small aircraft. The primary concerns 
reported by these pilots were thunderstorms and icing conditions. At the same time, very experienced 
pilots such as Collins (1993) report relatively high trip reliability (e.g., 94% of trips completed essentially 
as planned), even while scheduling these trips in advance before reliable weather forecasts are available; 
operating from the Northeast US with its difficult winter time conditions; and with a basic airplane (e.g., 
Cessna 182 without weather avoidance or icing protection equipment). Given weather avoidance 
equipment (e.g., radar, storm scope) and ice protection systems, experienced pilots report trip reliability in 
small aircraft that exceeds scheduled airline performance for practical purposes. Thus, airline-like 
reliability is achievable with current technologies for most classes of aircraft. That said, most pilots do not 
feel comfortable operating in hard IMC in small aircraft with minimal IFR equipage. They desire a 
greater degree of weather awareness and equipage including the ability to tactically avoid thunderstorms 
and manage icing encounters. These capabilities should be part of the basic, integrated system needed for 
robust, near-all weather transportation. 

4.2. Current and Emerging State of the Art 

Avionic systems on state-of-the-art small aircraft are rapidly becoming as, or in some regard more, 
sophisticated than the most sophisticated transport category aircraft. One reason for this trend is that 
certification requirements for small aircraft certified under CFR 14 Part 23 are less demanding than for 
transport aircraft certified under CFR 14 Part 25, thus accommodating greater innovation. Another reason 
is that the decentralized operations typical of small aircraft favor increased reliance on aircraft-based 
capabilities versus the ground equipage that is often favored by commercial operators. Examples where 
small aircraft are leading commercial aviation in the adoption of new technologies are use of Automatic 
Dependent Surveillance Broadcast (ADS-B) and synthetic vision systems (SVS) (e.g., 
http://www.alaska.faa.gov/capstone/) 

The impact of these innovations on the overall safety and utilization of small aircraft is not yet known, but 
some early observations are possible. First, certain types of accidents such as controlled flight into terrain 
(CFIT) can be largely eliminated. Figure 6 shows the number of CFIT accidents before and after 
mandatory ground proximity warning system (GPWS) equipage of turbine aircraft with 10-30 passengers. 
Given that CFIT is historically one of the top two most common fatal accident types, this trend suggests 
the overall safety rate should be significantly improved. 
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U.S.A Part 121 and Part 135 CFU Accidents 
Turbine Powered Aircraft, 10 to 30 Passenger Seats 



Figure 6: Effect of GPWS on CFIT accidents 
( http://www.egpws.conT/general information/description/effective.htm ) 


That said, these improvements do not come without some concerns. Early accident rates for certain 
technically advanced single-engine, GA aircraft have been comparable to existing aircraft, prompting the 
FAA and industry to investigate the phenomena and publish a report on “Technically Advanced Aircraft” 
or TAA’s (TAA Safety Study Team, 2003). Key findings are that technology can increase the “available” 
safety, but contemporary installations require additional aircraft/system specific training to take advantage 
of the equipment and that technology has the potential to increase workload and may distract the pilot 
from other important responsibilities. As noted in the TAA report, these issues are consistent with 
previous introductions of new technologies in aircraft and should not overshadow the overall benefits new 
technologies may offer. Of course, designers must also strive to learn from these historical examples in 
order to anticipate and minimize any adverse aspects of future designs. 

With technology currently available on certified small aircraft, the vehicle’s systems have access to much 
of the functionality and information critical to the successful conduct of a flight. Integrated navigation 
systems maintain continuous position awareness and combined with terrain, weather, traffic, and airspace 
data, represent a high degree of information about the external situation. Solid-state attitude, heading and 
air data sensors combined with full-authority digital engine control systems, digital autopilots, and highly 
automated secondary systems have a significant amount of information regarding the vehicle’s situation 
and actions. At present, much of this information simply passes through the vehicle on its way to be 
displayed to the pilot. The pilot is relied on to perceive the information’s significance, form an integrated 
understanding of the situation, develop potential actions, select a preferred course of action, and configure 
the systems to execute or assist the performance of these actions. This situation is the result of piecemeal 
technology evolution as individual systems were replaced by digital counterparts or augmented by new 
stand-alone systems (e.g., Traffic Collision Avoidance System, TCAS) without revisiting the basic role of 
the pilot or ability of the vehicle assist the pilot more effectively. Many vehicles appear autonomous 
because they can operate for long periods of time without any direct human involvement (essentially 
takeoff to touchdown), but are in fact only executing actions pre-sequenced by a human. Such a vehicle 
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has no understanding of the context or advisability of its actions, let alone how to modify them should an 
unanticipated situation arise. At the same time, the pilot is left with a passive monitoring task, which 
often has no negative consequences if not performed. As described by many authors on automation design 
issues (Billings, 1997 Bainbridge, 1983, Norman, 1990), this situation is prone to a variety of failures and 
breakdowns. 

As Norman (1990) remarks, 

“ Automation is at an intermediate level of intelligence, powerful enough to take over control that 
used to be done by people, but not powerful enough to handle all abnormalities. Moreover, its 
level of intelligence is insufficient to provide the continual, appropriate feedback that occurs 
naturally among human operations. This is the source of the current difficulties. To solve this 
problem, the automation should either be made less intelligent or more so, but the current level is 
quite inappropriate. ” 


Significantly improving the safety and capabilities of single -pilot operations in an increasingly demanding 
NAS environment is probably not achievable without reliance on sophisticated automation and thus 
requires following the path of more intelligent automation. In the remainder of this paper, a flight system 
concept for improved single-pilot operations is developed. This concept known as the Naturalistic Flight 
Deck (NFD) consists of largely existing, and often certified technologies, but strives to dramatically 
improve performance by developing a higher level of machine awareness and intelligence through 
information fusion and using this awareness and intelligence to create a new, more effective, partnership 
between the pilot and the aircraft. The NFD is described in the following sections by reviewing key 
concepts of human- machine interaction, describing the major system components, and then illustrating 
the operation and interaction these components through a selection of concept of operations scenarios. 

5. Theoretical Concepts 

Before describing the concept of operations, it is important to provide some theoretical perspective 
regarding the underlying assumptions in the design. Many of the concepts described later reflect a 
departure from the traditional way of thinking with respect to flight deck design. It is important for the 
reader to understand the mindset and framework of the designers in order to better appreciate the design. 
There are four primary theoretical concepts that will be discussed. The first is complementary automation 
or Complemation. This involves taking a very hard look at what the role of the human in the system 
should be and then designing the automation to support that role and overcome the human’s deficiencies. 
The second concept is Engagement. Providing effective and acceptable ways of keeping the pilot in the 
loop while not creating intolerable levels of mental and/or physical workload. The third concept is the use 
of metaphorical design as a method to reduce training time and increase pilot situation awareness with 
regard to the responses of the system. Different pilot roles and automation capabilities will require 
different metaphors. Finally, a distinction is made between actually doing something and thinking or 
planning about doing something so as to avoid confusion regarding what the automation is going to do 
and who/what is in control (human or automation). All of these concepts fit together in the holistic design 
of the flight deck. 

5.1. Complemation 

We live in a world where errors are made by humans and errors are corrected by humans. Humans make 
errors in design, manufacture, direction, operation, and maintenance. At every stage of implementation 
and execution, humans can introduce errors and mitigate them. Conventional thinking claims that 


15 



removing the human interaction and replacing it with machines will remove human error. However, this 
thinking overlooks two important considerations. The first is that humans are involved at some point in 
virtually every human endeavor, so it is nearly impossible to completely remove the human (e.g., removal 
of the human from operations via automation will simply move human errors to the design phase). The 
second consideration is perhaps more meaningful — the human’s ability to prevent and mitigate 
unforeseen contingencies or situations. 

Recent history is replete with examples of design, manufacturing, and maintenance errors causing severe 
failures (e.g., electrical power grids, airline and airport dispatch operations, and autonomous vehicles) that 
could have been prevented had there been the opportunity for some form of human intervention. In most 
of these cases the designers, manufacturers and maintenance personnel “failed to anticipate...” or “did not 
consider. . .” some combination of factors or occurrences. This situation is not surprising given that in 
complex systems there are essentially an infinite number of potentially significant factors and 
interactions. If a human had had some level of access to the system during operation, he might have 
performed a simple action, such as isolating a section of the power grid or correcting for an erroneous 
piece of data, that could have prevented or mitigated the failure. While supporting such access is often 
rejected based on statistics implicating the pilot as the top causal factor in current accidents (e.g., Figure 
4), it is extremely important to recognize that no comparable data is recorded on successful human 
interventions (indeed, we are not sure how such data could be collected), that is, the number of failures, 
errors, and ultimately accidents that are avoided or remedied by human actions. Without data on 
beneficial interventions, using accident statistics to advance the case that human pilots “usually” make 
things worse and thus their system access should be minimized or eliminated is misleading and would be 
like saying that because engine failures lead to crashes, engines cause aircraft to crash and should be 
eliminated. Based on such flawed logic, traditional automation philosophy tends to throw the baby 
(human prevention and mitigation abilities) out with the bath water (human error). 

Complemation (Schutte, 1999) or complementary automation offers a better alternative. Complemation 
does not remove the human from the operational aspects of the mission; rather it takes advantage of the 
human’s unique abilities. Complemation deals with errors that the human pilot could potentially introduce 
into the system by reducing the proneness of the system to human error, identifying human errors and 
making them apparent to the pilot, and providing prophylactic measures to insure that human errors do 
not propagate throughout the system causing a failure. Thus, the machine and the human work together in 
symbiosis. The human pilot provides common sense knowledge, general intelligence, and creative 
thinking while the machine provides swift and precise control, extreme vigilance, resistance to fatigue, 
and encyclopedic memory. The human pilot has many tasks but perhaps the most important one is to 
compensate for limitations of other parts of the system or put more simply, to handle the unexpected. 

5.1.1. Role Allocation and Support vs. Function Allocation 

Unlike machines, humans cannot be built-to-order by designers to perform specific tasks; at best they are 
trained to perform tasks but there are limits to training. Humans have a limited operational envelope and 
require specific information in order to do their job. They are limited in memory (Baddeley, 1998), 
endurance, and other abilities such as computation. If the human is required to perform outside of this 
envelope or without sufficient information, they will fail. For example, a human who is asleep and is 
abruptly awoken to perform an assessment and decision making task quickly will more than likely 
perform it poorly. One reason is that human mental processes are usually sluggish on awakening from 
sleep. They require time to warm up. Another reason is that the human has been blissfully unaware of 
what has been going on in the surrounding world while asleep. Making assessments requires data and the 
human has not been acquiring data. In addition, humans respond very differently under stresses such as 
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time pressure and in some individuals, reasoning under stress is extremely difficult. 

In the past, allocating tasks to the human or the automation has usually followed a Fitt’s List approach 
where a task decomposition was performed on the mission and tasks were assigned to whomever could 
perform them best. There are several flaws in this process. The first assumes that humans can perform the 
task well in isolation - that is, without any context or involvement in other tasks. For example, humans 
are better at performing qualitative value judgments and pattern recognitions. However, if the automation 
has been assigned tasks that remove the human from the information used to make these assessments, 
then the human will be hampered in performing them. Humans like to perform continuous, logical, and 
meaningful tasks in context, while the automation can easily perform every other step with the same 
accuracy as if it performed every step. The point here is not that humans have to be involved in every task 
but that the tasks must be grouped or chunked into meaningful and logical sets and assigned based on 
those sets. The second flaw in this argument is the premise that the tasks that humans do better than 
machines are tasks that humans do well. This is often not the case. Often the tasks that humans do better 
than machines are difficult even for humans. Thus the human is assigned the most difficult leftovers 
resulting in a high probability of an eventual human error. Y et another problem with traditional function 
allocation is that machines do routine things very well and therefore are usually assigned these tasks. This 
would be fine except it leaves the human with little to do most of the time and the human may become 
bored or complacent, ultimately loosing the necessary level of awareness needed to effectively understand 
the status of the mission and automation and leaving them vulnerable to potentially life-threatening 
surprises. As a result, pilots often refer to flying modem, highly automated aircraft as hours of boredom 
punctuated by moments of terror. 

For these reasons, a new allocation strategy is required. The one that is proposed for this project is based 
on the general role that the human is going to play in the mission (including the roles the human may be 
called on to play in non-normal situations). The knowledge, skill, information, and control requirements 
are determined for performing these roles. The next step is to determine where the human may be weak 
and can use some help. The machine is then designed around those needs. The reason for this approach is 
that humans are less ‘designable’ than machines. We can design a machine around a human but we cannot 
design a human around a machine. At best, we can train the human but that has its limits, is costly and 
ultimately results in an increased probability of serious errors. 

We propose that the human has the following roles in the NFD. First, the human is a mission director - 
choosing where to go, when to go, approving how to go, and when to make major changes in the plan. 
The next role is a consequent of the role of director and that is the role of mission troubleshooter. In this 
role, the human must monitor the status of the mission, environment, and airplane relative to expectations 
to identify and resolve issues that will or may impact the success and safety of the mission. Resolutions in 
this role would tend to be discrete decisions and actions such as modifying the flight plan to divert around 
an area of thunderstorm activity in response to loss of tactical weather information. The final role for the 
human is as a back-up for selected automation functions. This differs from the role of troubleshooter in 
that not only must the human decide on a remedial action, he or she must take an active role in replacing 
some functionality of the automation. For example, if the automation normally negotiates with ATC over 
data link, the pilot may have to step in and use voice communication if the data link system onboard the 
aircraft fails. 

Each of these roles has certain fundamental information and control requirements. However there are 
additional requirements that must be met because the agent performing these roles is a human rather than 
a machine. For example, suppose that a requirement for performing a role is positional awareness. A 
machine can instantly read positional information and process it - even if it has not been monitoring that 
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information. Humans, however require more time if they have not been monitoring this information than 
if they had been monitoring it. If they already have this information in their heads, humans often perform 
as swiftly as machines in making their assessments. But, if they have to ‘fill up their heads’ with the 
information, there can be a significant delay and processing deficit. In summary, there are requirements 
for performing in the role in general, and there are additional requirements for humans performing in the 
role. 

5.2. Engagement 

As hinted at above, getting information into the head or working memory of the human is one of the more 
difficult tasks. There is limited input bandwidth, the human can only focus on a limited area of that 
bandwidth at a time (e.g., auditory inputs are often ignored in the presence of strong visual or tactile 
inputs (Best, 1999)), and the human may forget previously received information. Humans are quite adept 
when it comes to prioritizing mental tasks and if there has been no reason for attending to a channel of 
information over a period of time, the human will stop attending to it. If we are watching a machine or 
another person perform the same task flawlessly over and over again we will find it hard to attend to it - 
even if we are expected to monitor that task. Our minds are naturally wired to attend to more dynamic 
things and tune out monotonous things regardless of importance. These states of tuning out could lead to 
what Pope (Pope & Bogart, 1993) refers to as a hazardous state of awareness. Hazardous states of 
awareness include high workload times where the human is stressed but also extremely low workload 
times where the human can become complacent or bored. While humans can be trained to counter this 
tendency, training only goes so far and is often time consuming and costly and many individuals will 
never achieve sufficient ability (e.g., individuals with attention deficient disorder provide an extreme 
example). 

The challenge for the designer is to have the pilot update his mental model at an appropriate frequency 
without becoming annoyed. A classic example of this in aviation is the use of position reports. For 
oceanic flights, which are particularly monotonous, pilots are required to report their position at regular 
intervals. 

The primary purpose of this task is to keep air traffic control aware of the aircraft’s location since it is out 
of radar coverage, however it also serves to update the pilot’s mental model. This procedure is effective 
because the primary purpose of the position report is not to update the pilot’s mental model - if that were 
the case the pilot might consider it busy work. Humans like to have meaning in their lives and they like to 
do things for a purpose. The NFD concept seeks to keep the human’s mental model up-to-date by 
providing active involvement in flight activities - specifically the human will initiate significant speed 
and trajectory changes at the time of execution. This is a radical departure from current automation trends 
toward preprogrammed flight. It appears to be underutilizing technology. However, this is only true from 
the traditional function allocation approach. That is, traditional functional allocation would state that 
because machines are more vigilant and have better memory than humans, they should be responsible for 
making speed and trajectory changes based on a preprogrammed route. However, from the role support 
perspective, this severely handicaps the human as mission director because now the human must 
remember what was programmed far into the future. In addition, the human must remember how the 
machine will execute the programmed commands. And since the machine will perform the task very 
reliably 99.9% of the time, the human will probably not be vigilant and paying attention during that 0.1% 
of the time where he or she is required to become involved. This loss of awareness and resulting 
confusion frequently manifests itself in modem commercial flight decks where the pilots misidentify what 
mode the aircraft is in, what automation system is currently controlling, or what the next automated action 
will be. 
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So the reasoning behind the design of the NFD goes as follows: What is the role of the pilot on the flight 
deck? Mission director. What information does the mission director need to know? In part, where the 
aircraft is going, how it will get there, and how the aircraft is performing compared to expectations. What 
is an effective way to impart this information to the pilot? Have the pilot direct the actions of the aircraft 
at the time of significant trajectory changes (e.g., transitions between legs, interception of an approach 
procedure). What are the problems and weaknesses associated with the pilot performing this task? 
Difficulty in achieving or maintaining precision, difficulty in remembering when to make the changes, 
and assuring a safe course of action should a nominal change be missed. How can automation assist the 
pilot in dealing with these weaknesses? The answer cannot be, have the automation fly the aircraft on a 
preprogrammed flight because then the pilot will not be ‘doing if at the time of execution. One solution is 
to use automation to adapt to the human’s state of engagement in the task by dynamically allocating and 
deallocating tasks to the user based on their current state of engagement - i.e., a feedback loop (Prinzel, et 
al, 2000). However, this approach requires some way of monitoring the human’s state of engagement 
(Pope has been successful in using EEG (Pope, Bogart, & Bartolome, 1995)). 

Additionally, adaptive automation has the potential for confusing the user if inappropriately implemented 
because the user might not know what to expect from the automation. Rather than try and provide a near 
optimum state of engagement via adaptive automation, we suggest using a static allocation of 
human/automation tasks that will allow the user to be more consistently engaged throughout the flight. 
Our answer is to deal with the precision problem by having the pilot specify the high-level parameters and 
using the automation to maintain these parameters with precision, deal with the memory problem by 
providing reminders and alerts to the pilot to direct the high-level changes, and assisting the pilot in 
developing and executing a recovery plan in response to an error of omission. At face value this solution 
appears counter intuitive - if the machine knows that a turn needs to be made and knows how to make it, 
why not just have the machine make it? Because the human is removed from the task and is not as aware 
of what is happening than if he or she were involved in making the turn. Since the system is providing 
cues for speed and direction changes, isn’t the human just becoming a ‘meat servo’ or ‘monkey in the 
cockpit’? We would argue no. The human who has been involved in previous events is more likely to be 
situationally aware and to recognize a directive that is inappropriate than one who is just watching the 
automation. While this claim requires experimental validation, it is certainly intuitively sensible. In 
summary, one possible solution using the Complemation approach is to have the pilot make all high-level 
speed and direction changes in the aircraft and to have the automation make inner-loop corrections and 
act as a reminder to the human for making the changes. This design solution keeps the pilot engaged in 
the task in a meaningful way and that engagement reinforces situation awareness. 

This approach appears to increase in-flight workload over the current automation approach. However, we 
believe that it serves to even out workload across the mission as opposed to the ‘hours of boredom, 
moments of terror’ workload profile. If the pilot had to perform all continuous control and stabilization 
tasks, the physical workload might be too intense. However, the number of high-level speed and direction 
changes during a mission is usually quite manageable. The famous Yerkes-Dodson law states that a 
moderate level of stress and activity improves human proficiency, whereas both high and low levels 
decrease proficiency. The ‘hours of boredom and moments of terror’ approach appears to operate in the 
low and high stress zones of least proficiency while skipping over the higher proficiency levels. While 
this approach should even-out physical workload to more desirable levels, additional design strategies 
may be required to address mental workload concerns. 

5.2.1. Reducing Cognitive Distance rather than Workload per se 

Modern automation has been found to shift the pilot’s workload from the physical to the mental rather 
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than reducing workload across the board (Wiener, 1988). Why is this true? We believe that it occurs for 
two primary reasons. One is that the pilot has an increased memory burden in that he or she must 
remember what the machine was programmed to do and how it will do it over long periods of time. The 
second reason is that the pilot must span a conceptual distance that Norman calls the gulf of execution and 
the gulf of evaluation (Norman & Draper, 1986). For example, if ATC gives the pilot a directive, the pilot 
must first translate that directive into a target that the automation will understand. Then the pilot must 
recall the programming steps necessary to enter that target into the flight management computer. These 
two steps are not part of the task of flying from A to B. They are entirely peculiar to the automation. The 
pilot knows what he or she wants to do and knows that the machine can do it. Flowever there is a distance 
that must be crossed to translate what the pilot wants into what the automation needs to fulfill that 
command. This is called the Gulf of Execution. Similarly, once the flight management computer has been 
programmed, it can be difficult to determine if what the machine is programmed to do will actually fulfill 
the goal of the original directive. The pilot must translate what the machine is saying that it will do back 
into the language of the original directive. This translation is the Gulf of Evaluation. These mental 
translations and procedures do not have to do with the mission. They are a diversion along the path from 
goal to execution and back again. 

One way to decrease mental workload without sacrificing situation awareness is to decrease the cognitive 
distance imposed by the automation on the gulfs of execution and evaluation (Schutte, 2000). One elegant 
approach to dramatically decreasing this distance is Riley’s Cockpit Control Language (Riley et al., 1998) 
which allows the pilot to input ATC-like directives directly into the Autoflight system. The NFD will 
have as one of its design goals to remove as much machine/design induced cognitive distance as possible. 
Our goal is to have the pilot think about flying, not programming or getting the automation to work. Thus, 
the pilot will be more involved and engaged in the flight and mission itself than they would in more 
automated flight decks and yet will have lower physical and mental workload peaks. 

5.2.2. Engagement as preparation for troubleshooting and back up 

Another important benefit of increased pilot engagement in the flight is that it helps to reduce skill loss - 
a major issue if the pilot is called on to troubleshoot or act as a back up. In the event that some part of the 
automation or aircraft fails, the pilot will have a better understanding of what should happen because they 
have been involved in the task on many previous flights. For example, suppose some aspect of the 
guidance fails on approach. The pilot will have to depend on himself or ATC or some other form of 
guidance to assist him. Flowever, he will know roughly what will need to be done because he has been 
involved with the task many times before. Fie can anticipate what the automation would have done if it 
were active. If guidance fails on a modem commercial aircraft, the pilot is left with an entirely different 
task (manually flying via the stick or wheel and column) as opposed to programming information into the 
FMS. 

In addition, the pilot will have an additional opportunity to recognize and avoid mistakes. For example, if 
the pilot of a traditional FMS makes a mistake in programming the route such as entering in the wrong 
altitude for a waypoint that is several hours into the flight, he or she will be less likely to catch that 
mistake when the machine executes the altitude change. The machine will start the change and the pilot 
repeats the well-worn automation phrase - “What is it doing now?” They would have to troubleshoot to 
determine whether this is a problem and when they discover that it is, then they would have to correct it. 
If, as in the NFD design, the pilot is given a guidance cue to move the aircraft, he will have a chance to 
intervene before the action is taken. The question now becomes - “Why would I want to do that?” But 
the pilot would still be in control. In the automation example, the pilot has relinquished control for a 
period of time while they determine if there is a problem. This certainly will not guarantee that errors 
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won’t happen, but it will give the pilot additional opportunities to notice and address them before 
significant reductions in safety margins occur. 

5.3. Artificial Intelligence and the Use of Metaphors in Interface Design 

Shortening the cognitive distance in design is not a simple task. Computers do not reason in the same way 
humans do. The human brain is not just an organic digital computer. This is not to say that computers 
cannot be used to simulate brain-like and human-like behaviors, but the underlying logic and ‘hardware’ 
is fundamentally different. Modeling the activity of a single human neuron often requires a great deal of 
computer code - and as with all simulations, there are usually situations where the model fails to replicate 
the actual neuron. The point here is that creating artificial intelligence at the interface level, the 
conceptual model level, or at the neuronal level is extremely challenging. Thus being able to directly 
interpret a human’s goals and desires is possible at best in limited situations and structured domains 
(especially at the levels of reliability required for certification on aircraft). 

Fortunately, the aviation domain is relatively structured. The formal communication vocabulary is 
relatively small and the laws of operation (e.g., physical laws of aerodynamics and the airspace rules and 
regulations) are also fairly well defined and can be codified. 

Many attempts have been made over the years to use artificial intelligence to interact more naturally with 
pilots with varied success (e.g., Pilot’s Associate (Smith & Broadwell, 1986), Rotorcraft Pilot’s Associate 
(Miller & Flannen, 1999), and CAMA (Onken, 1999)). We believe that the many of the limitations that 
these programs have encountered are largely due to applying an inappropriate metaphor for the interaction 
between the human and the machine, particularly in time-critical situations. 

There are basically four types of interaction metaphors commonly used with artificial intelligence. The 
first is the human metaphor where the automation is modeled to be the equivalent of another person. This 
is the most frequently cited metaphor in artificial intelligence applications. The second and third 
metaphors are less common yet we believe that they have greater overall power in facilitating effective 
human-machine interaction in many situations. The second metaphor is that of a domesticated animal, 
e.g., a trained horse or trained dog. In this metaphor, the machine has intelligence and specialties but is 
not portrayed as the equal of a human. The third metaphor is the body metaphor where the machine is 
considered to be an extension of the body. The intelligence in the automation used in this metaphor is 
akin to that of the sub-conscious functions of the cerebellum, portions of the midbrain, brainstem, and 
central nervous system. The fourth metaphor is the tool metaphor that basically uses some human artifact 
that the pilot already has familiarity with to explain new functionality. Examples of tool metaphors are the 
desktop metaphor for computers (you manipulate files just like you would on a desktop) and the 
automobile metaphor for aircraft (flying an airplane is just like driving a car). Each of these metaphors 
will be briefly described along with some comments on their appropriate usage. 

5.3.1. The Human Metaphor 

The human metaphor as applied to artificial intelligence usually takes the form of an associate, assistant, 
agent, or employee. In the aviation domain they would replace the copilot or flight engineer or some other 
specialty on the mission. Indeed, in fully autonomous unmanned vehicles or autonomous wingman 
aircraft, these systems may replace the human pilot. Some associate systems are quite impressive in their 
ability to reason and communicate like a human. The human metaphor is usually the best metaphor to use 
when trying to interpret and understand the goals of the pilot and to communicate complex, abstracted, or 
conceptual information back to the pilot. One can express complex thoughts and goals to another human 
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more easily than to a machine. Machines based on the human metaphor are often called on to provide 
knowledge-based reasoning, information, and behavior as opposed to skill-based behaviors. They often 
use natural language recognition and synthesis along with pictures and sounds to interact with the pilot 
just as a human would (humans do not come with keyboards!) 

Of course, this metaphor is one of the most difficult to fully realize. In most cases only portions of human 
intelligence are emulated. What often occurs in these situations is the pilot assumes that the machine is 
either more intelligent or has a broader range of intelligence than it actually has. Humans tend to 
anthropomorphize even the simplest machines (Reeves & Nass, 2003) so machines that have human-like 
intelligence are easily anthropomorphized. The pilot may expect the machine to have common sense and 
know as much about him as he knows about the machine; and when the pilot expects or depends on 
something that is not within the machines capability there can be problems. Ultimately, the requirement 
for the pilot to understand and accommodate the machine’s limitations translates into cognitive distance 
for the pilot. That is, the pilot must remember that while very human like in most ways, the machine does 
not have these other capabilities that a human normally would. 

Thus, for the foreseeable future the best use of human metaphor type of artificial intelligence is in 
situations that do not require a great deal of breadth and depth and allow sufficient time for the pilot to 
work with the machine. In the aviation domain, these types of systems are best used in non-time critical 
tasks where the human can dedicate attention and concentration to the interaction. Thus, the human 
metaphor (that of an aid or assistant) is used in implementing the strategic and planning automation for 
the NFD. 

5.3.2. The Domesticated Animal Metaphor 

In this metaphor, the machine acts as an obedient animal. It can understand simple commands and it is 
highly depended on for its skill-based behaviors but not its knowledge-based behaviors. The domesticated 
animal metaphor chosen for the NFD is the horse or “H-metaphor” (Flemisch et al., 2003). The H- 
metaphor has several dimensions of particular relevance to vehicle automation. A horse is extremely 
adept at locomotion in various terrains and conditions such as running in close proximity to other horses. 
Similarly, a horse can avoid immediate hazards while continuing to support the rider’s near-term 
objectives. It has a limited but flexible set of communication skills that can be used to direct a range of 
high-level or “loose rein” behaviors such as used in calf roping, and low-level or “tight rein” behaviors 
that provide nearly direct control over the horse’s motions as used in dressage. The rider does not 
necessarily have intimate awareness of individual muscle movements or internal bodily activities of the 
horse. 

There is generally a multi-modal interaction with a significant degree of physical, haptic contact that 
facilitates a largely subconscious, bi-directional communication link between the “wills” of the human 
and animal. This link is in many respects similar to the body metaphor described below, albeit between 
collaborative intelligences rather than within a single integrated intelligence. The haptic connection 
allows a rider to remain in contact with the “maneuver management automation” provided by the horse 
with little use of visual and cognitive resources. Short-term goals and behaviors can be efficiently 
communicated to the horse and the horse can contextually interpret and support these goals or recognize 
conflicts requiring modification of the goals. At the same time, horses rarely know the high-level goals or 
mission of their riders (except in TV and movies) and the human must give simple, frequent commands 
such as turn left, run, stop, jump and sidestep in order to achieve their mission. This is not to say that a 
machine based on the horse metaphor will not act autonomously. For example, a horse will instinctively 
avoid hazards or seek food if it is hungry. Furthermore, if there is no rider or the rider is incapacitated, the 
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horse will return to its bam or the nearest safe area it can find. Finally, a horse may challenge the rider if 
his commands are perceived as dangerous. 

In contrast to the human metaphor, the horse metaphor is well suited for machines that operate in time- 
critical and flight-critical situations. This is because the language set between the pilot and the horse is 
sufficiently small and because automation that performs horse-like behaviors (such as auto land systems) 
has already been certified. In addition, the horse metaphor is well suited for implementing the concepts 
described earlier in the Complemation section. The human gives high-level commands to the horse and 
the horse immediately carries them out. Again, horses that can carry out a long string of commands (e.g., 
‘go to the end of the block, turn left, travel for two miles, turn right . . .’) are rarely found in the real world. 
Thus, the horse metaphor is used in implementing the automation for the real-time, tactical behaviors of 
the aircraft. 

5.3.3. The Body Metaphor 

The third metaphor places the machine as an extension of the pilot’s body (either literally such as a 
robotic arm as an extension of the human’s arm, or conceptually such as making the engine of an aircraft 
feel and react as if it were a body part). In the body metaphor, the machine enhances, empowers, and 
extends the human’s abilities. The human applies their skill-based talents and behaviors and they are 
enhanced to superhuman capability. The intelligence associated with the body metaphor is similar to that 
of the cerebellum, certain parts of the mid-brain, brain stem, spinal cord, and autonomic nervous system. 
The machine based on the body metaphor offers the pilot faster and more precise reactions, greater 
sensing capability, an expanded range of capabilities, and greater strength. The pilot has a keen awareness 
of the configuration, fitness, and performance of their extended body and they have greater control over 
individual systems and effectors. In the horse metaphor, the pilot cannot command exact position of an 
aileron nor is the pilot able to directly sense the functioning of the engine in detail. In the body metaphor, 
the pilot can. Thus, the body metaphor is most useful when the pilot must apply his skills to the task at 
hand and must make tactical decisions with the overall strategy and goals constantly in mind. The body 
metaphor is described further in (Schutte, 1997). 

The body metaphor is perhaps most useful for assisting the pilot in the back-up role. When the pilot is in 
the role of back up, it is likely that the workload level will be higher. Any assistance that the automation 
can provide in making the role of back-up as intuitive as possible is welcome. In these cases, the human 
may perform the machine’s role best if he can get into its skin. 

5.3.4. The Tool Metaphor 

Tool metaphors in design have an advantage in that they are mapping some interaction or functionality 
from one artifact to another artifact. The original artifact is usually very simple (unlike the more complex 
living organism metaphors above) and therefore, easier to implement. That is, it is much easier to make a 
word processing program ‘behave’ like a typewriter than it is to have the word processor act like a 
secretary. Like the other metaphors, tool metaphors are very useful when the new system performs 
functions similar to those that the metaphor performs, such as the typewriter/word processor example. 
Where they are significantly different from the earlier metaphors is in that tools are rarely as general 
purpose as the organic metaphors. For example, if the human metaphor were used in designing and 
describing a word processor, it would not be difficult to also add a drawing function to the program. 
However if the typewriter metaphor is used, it is difficult to add the drawing functionality and continue to 
use the metaphor. It is very hard to draw using a typewriter. The designer would more than likely have to 
use a second tool metaphor (a pencil or brush) for the drawing task. 
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5.3.5. The Advantages of Using Metaphors in Design 

There are several benefits in using metaphors in design. The first is that it provides some design guidance 
and boundaries for the designer. When the designer has a design choice he can consider how it would be 
handled in the appropriate metaphor. The designer can ask, “Is this consistent with what a horse would 
do, or what a person would do?” 

Another major advantage is in training. Most humans have at least some experience interacting with 
humans, domesticated animals, their own bodies, and certain general tools. To a greater or lesser degree 
they know how to interact and what to expect out of that interaction. A significant amount of interaction 
and behavioral knowledge is already in place in the pilot’s mind before beginning any training; 
significantly reducing training costs. To tell an ab initio pilot that the aircraft will respond to their 
commands in a way similar to a horse conveys a significant amount of information. The task for the 
trainer is then to fine tune that information so that the pilot fully understands what the system will or will 
not do. 

5.3.6. The Dangers of Using Metaphors in Design 

There are, of course, downsides to using metaphors in design. The first is that it may overly constrain the 
design. There may be a design feature available to the designer that would be highly beneficial and yet is 
inconsistent with the metaphor. For example, the use of voice communication from the system would be 
inconsistent if the system is designed using the domesticated animal metaphor. It is tempting and often 
quite appropriate or even necessary for the designer to depart from the metaphor in one or more aspects of 
the design. But that can lead to the second problem - inconsistencies with the metaphor. The classic 
example of this is the desktop metaphor in personal computers. The idea of storing files in a filing cabinet 
and in folders is extremely intuitive. So having a file system in a computer explained in terms of folders is 
very helpful for understanding how it works. However, the metaphor quickly breaks down when one 
considers that applications are also stored in the file cabinet in folders; one rarely stores a typewriter in a 
file cabinet. Similarly, on a real desk, when someone puts a piece of paper on the desktop, it is no longer 
in the file cabinet at that time. And when they change that piece of paper it remains changed even if the 
power goes off. But in the computer, when the user opens a document, it still exists in the file cabinet (the 
hard drive) and if the power goes off - all changes that weren’t saved are lost. The user must ‘unlearn’ 
some of what they know about the interaction with the metaphorical system. This negative transfer can 
cause confusion - especially if the system is consistent with the metaphor in many other respects. Still 
another problem is that users can expect too much from a system that has been designed and trained using 
a metaphor. This often happens when the human metaphor is used and the user assumes that the system 
has some common sense greater than what it really has. Finally, a user can harbor negative memories 
regarding the metaphor source that may discourage their interaction. For example, if a pilot is told that the 
system behaves like a horse and their experience with horses has been that horses are temperamental, 
dangerous, or difficult to control they may be turned off to the system from the very beginning. All of 
these issues must be considered when using metaphors in design. If they are not, a valuable design asset 
can become a liability. 

5.4. Actual (tactical) and Notional (strategic) behavior 

As mentioned above, the NFD uses the Horse metaphor for aircraft’s tactical behaviors and a human 
metaphor for the strategic behaviors. What is a tactical behavior and what is a strategic behavior and how 
do designers determine what tasks and functions belong in each category. While the terms “tactical” and 
“strategic” are generally understood by most people; they are very difficult to define. Often time or 
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physical distance is used as a discriminator but the actual values for these discriminators vary greatly 
depending on context. Context elements that affect these discriminators are phase of flight, workload, 
urgency and threat, priority, and the type of task being performed. Another confusing factor has to do 
with deciding which task is being discussed. For example, the pilot, in cruise, decides to arrange for some 
maintenance after landing. Fie calls to the ground service center to arrange it. When the pilot is making 
this call, is he performing a tactical or a strategic behavior? It is strategic in that it has to do with 
activities relatively far in the future. But it is also tactical in that he is making the call right now (there 
may even be a sense of urgency regarding it - to reach an office before it closes). Many tasks have both 
tactical and strategic elements to them. 

For the NFD, we have selected slightly different concepts that are more crisp and definable. Rather than 
discussing a behavior as tactical or strategic, we define it as Actual (doing) or Notional (planning to do or 
reviewing what was done). In addition, we add another element of the definition - the object being acted 
on. In this example, if the object of reference is the aircraft itself, it is clear that the call is a Notional 
behavior because nothing is actually happening to the aircraft. The call may affect what happens on the 
aircraft in the future but this is not guaranteed because there are so many possibilities. If the object of 
reference is the radio then the behavior is Actual because the pilot is actually using the radio - what he is 
doing is changing/affecting the radio. 

When a person is planning a flight, he can be viewed as making an imaginary flight. The aircraft is a 
notional representation - not the actual aircraft. The aircraft might be represented by a pencil mark on a 
map (a notional representation of the earth and terrain) or ones and zeros in a computer. When the pilot 
moves this representation, the actual aircraft does not move. It is only its representative that moves. The 
definition of Actual and Notional can then be written succinctly as follows: 

Reference Object: the object that is being manipulated, being observed or is observing. 

Actual Object: a Reference Object that exists in the real world at the current time. 

Notional Object: a Reference Object that exists only as a representation of a real world object and 
is not the object itself. 

Actual Manipulation: manipulation of an Actual Object (i.e., a Reference Object that really exists 
in the real world.) Also known as Actual Control. 

Notional Manipulation: manipulation of a Notional Object (i.e., a Reference Object that is 
fictitious and only represents an object in the real world.) Also known as Notional Control. 

The key aspect to this dichotomy is that nothing that is done to the Notional object will ever affect the 
Actual object. This is not the case in modem commercial transports where the Flight Management System 
(FMS) is often viewed as a strategic device while the “stick and rudder” and autopilot are viewed as 
tactical devices. If the autopilot is responding to commands from the FMS (i.e., coupled to the FMS), 
then inputs and changes in the FMS will affect what the aircraft does. If it is not Hilly coupled then those 
changes will not necessarily affect the aircraft. And there are a host of intermediate configurations where 
the changes may or may not affect the aircraft. The result of this ambiguity is often mode contusion, 
leading the pilot to ask the question, “What is the aircraft doing now?” or “Who is in control now?” The 
Actual/Notional distinction eliminates this confusion. There is one set of controls and interactions that 
cause the aircraft to move and these are the only controls that will cause it to move. When you or the 
automation manipulate these controls, they will move the aircraft (within physical limits, of course). 
There is a different set of controls for the Notional system and these will never affect the aircraft. There 
is no confusion regarding which system is controlling the aircraft - it is always and only the Actual 
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system. 


5.5. Roles, Engagement, Metaphors, and Behaviors: Tying it all together 

When all of these theoretical concepts are combined, they lead to a consistent and robust human-machine 
interaction scheme. The pilot plans the flight aided by the Notional system. The Notional system 
interacts with the pilot using the pilot’s terms and goals (not necessarily natural language). The Notional 
system insures that the route is safe and legal, and it is responsible for storing all of the planning, aircraft 
and airspace rules and procedures. The plan is then provided to the pilot and the Actual system as 
guidance for executing the flight. The pilot receives route and task guidance from the Actual system that 
includes a robust reminding and alerting capability. However, the Actual system normally does not move 
the aircraft autonomously based on that guidance 1 . The pilot must direct the aircraft to act using the H 
metaphor. In this interaction metaphor, the pilot nominally provides high-level directives (e.g., perform a 
standard takeoff/departure, following the indicated path) through the H-inspired multi-modal interaction 
or “H-mode”. The H-inspired automation, or “H”, reacts by interpreting the directives and providing the 
necessary inner-loop control actions. The pilot must actively engage during significant course/velocity 
changes since the H will simply continue its current behavior so long as safety is not an immediate 
concern. The H (based on the guidance provided by the Notional system plus any external directives such 
as from air traffic control) will provide robust alerting cues so that the pilot will not inadvertently miss a 
high-level change. If a planned or prescribed high-level change is missed, the H (after providing highly 
salient queries of the pilot) will assume that the pilot is not responding and will activate the self- 
preservation mode and ‘fly back to the closest bam’ while declaring an emergency to the surrounding 
airspace. Note, this does not imply that the aircraft will only fly along pre-planned routes — if the pilot 
wishes to deviate from a planned route for any reason (e.g., by “missing” change or simply maneuvering 
off the route), the H will not hinder this free maneuvering so long as the pilot positively responds to its 
queries, and the deviation does not create immediate safety concerns. In this free maneuvering mode, the 
H continues to provide envelope, conflict, and hazard protection but otherwise allows the pilot to 
maneuver the airplane. 

During the flight, the Notional system, which created the plan using forecasted and predicted data, will 
constantly compare the predictions to real conditions or updated predictions. When there is a significant 
difference or change (e.g., weather cell moving faster or airport closure) the Notional system will signal 
the pilot that replanning is advised. 

The Actual system must allow the pilot to efficiently make any near- term (tactical) actions using only the 
Actual displays and controls (i.e., not needing to use the Notional system). In current modem commercial 
transports, if the pilot has to make a runway change on approach, there is only one place that contains the 
language for achieving that - the FMS. The autopilot does not have any representation of runways. As 
will be described below, maneuvers such as changing runways using the Actual system are as simple and 
straightforward as changing lanes on the highway. In the NFD design, there is no need for the pilot to use 
the Notional system to assist in a tactical maneuver. There is no advantage whatsoever and therefore 
there is somewhat of a disadvantage to do so because it means that the pilot must interact with two 


1 The Horse or H may appear to be following the guidance when reacting to a safety threat. However this is 
coincidental in that the most logical and safe response happens to match the initial guidance. For example, if the 
aircraft has been cleared on an approach procedure in the terminal area and the pilot becomes incapacitated and is 
not commanding the aircraft, the H will not want to continue flying the last command given by the pilot because that 
might drive the aircraft into terrain and other traffic. The H will want to get on the ground. The safest way would 
be to follow the cleared path, but it is not doing so because of the guidance per se. Indeed, in this case, the H would 
be automatically declaring an emergency. 
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systems. Any advantage of using the Notional system for tactical control should be considered to be a 
failure of the design of the Actual system. 

In this design concept, the pilot as mission director plans the mission and then has a role in executing it 
(figure 7). The pilot is a key link in both the planning loop and the execution loop. In most cases, the 
pilot is executing a plan that he created and thus this acts as a check on his own planning. A maneuver in 
a plan that made sense before the flight might not make sense at the point of execution. If for some 
reason the plan was incorrect or inconsistent with the pilot’s goals and intent, there is a greater chance of 
him becoming aware of this discrepancy if he is involved in the execution. This awareness supports the 
pilot’s role as troubleshooter in that he is ‘spooled up’ with the situation when an anomaly occurs. 
Situation awareness is one of the most important factors in decision making (Klein et al., 1993) and 
supports the pilot in making good troubleshooting decisions. If some aspect of the primary mission (e.g., 
guidance, H feedback, H control, Notional system) should fail or become degraded in flight, the pilot will 
have been actively involved in those decisions and will have observed the automation’s role repetitively 
in normal operations such that he can take on that role with moderate success if needed. Thus the back up 
role is supported. There are other aspects of the design that support these roles that are not discussed in 
this section (e.g., mission status graphics, communication Complemation, on-line information and 
instruction information) but will be discussed later in the document. 



Human is in the loop twice 


Notional 


Actual 


Figure 7: Dual role of the pilot assists in error prevention 

6. NFD Components 

In this section, the major components of the NFD system are described. First, the functional roles and 
responsibilities of the pilot and the aircraft, including its automation, are developed. Each function has its 
own information, action, authority, and responsibility requirements. For the aircraft, these functional 
requirements are implemented via the two major interface system segments, the Actual and Notional 
Systems. As discussed previously, this separation is intended to simplify the pilot’s task of maintaining a 
useful level of situation awareness and avoidance of mode confusion. The Actual and Notional systems 
are described in sections 6.2 and 6.3 respectively. 

6.1. Assumptions 

Currently, there is a great deal of research and development in the aviation domain. Technologies such as 
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data link systems, synthetic vision systems, advanced sensing instrumentation, graphical weather 
information systems, self-separation systems, and automated safety systems. In addition, there are several 
potential airspace innovations on the horizon (e.g., NEXTGEN and its potential elements such as DAG- 
TM and 4D RNP). The NFD concept will make use of all these technological innovations when possible 
and needed. And the NFD concept will be adaptable to current as well as potential new airspace concepts 
and rules. Perhaps more importantly, the NFD will provide a framework in which new and unforeseen 
technologies can be inserted in a consistent manner so that the pilot-machine interaction is consistent with 
the rest of the pilot’s interaction experience. 

6.2. Roles and Responsibilities 

Functions are allocated to the pilot first since humans are less designable than machines, then the 
automation, and to other services based on the roles that they are assigned in the flight deck. Palmer et al. 
(1994) describe roles that must be considered for both the human and the automation when designing 
human/machine systems. For the human, these roles are team member, commander, individual pilot, and 
occupant. They are defined as follows: 

■ Pilots as Team Members : This reflects the role of pilots as members of a team that includes not 
only the other flight crew members, but also elements of the flight deck automation, and in the 
larger context, elements of a distributed system including air traffic controllers, airline dispatch, 
regulatory agencies, etc. The issues involved include the need for communication, coordination, 
and shared functional understanding among all team members to successfully accomplish tasks. 

■ Pilots as Commanders'. This reflects the role of each pilot, individually, as being directly 
responsible for the success of the mission. The issues involved include the level of pilot authority 
over the flight deck automation, and the ability of the pilot to delegate tasks. 

■ Pilots as Individual Pilots : This reflects the role of pilots as individual human pilots working 
within a complex system of controls and displays. The issues involved include many of the 
traditional human factors disciplines such as anthropometries, control/display compatibility, and 
cognitive processing. 

■ Pilots as Occupants'. This reflects the role of the pilots as living organisms within the flight deck 
environment. The issues involved include ingress and egress capability, protection from the 
radiation and atmospheric conditions at the expected cruise altitudes, and accommodation of 
items such as food and drink containers. (Palmer et al., 1994) 

We expand on these definitions in the following ways. The role of Commander is defined explicitly in 
terms of the mission and is thus called Mission director. The role of Individual Pilot is made more 
explicit by defining what the pilot should be responsible for - in this case, Troubleshooter and Back-up. 

For the automation, Palmer et al. (1994) define roles more in terms of levels of automation, calling on the 
automation to perform one of the following roles: Substitute, Augmenter, and Aid. In the substitute role, 
the automation replaces a function that the human would normally perform (e.g., autopilot). In the 
augmenter role, the automation provides active assistance to the pilot’s actions (e.g., yaw dampers, 
envelope protection). In the aid role, the automation provides information collection, integration, and 
presentation. 

For the NFD, we are more explicit with regard to what the airplane and automation will be doing with 
respect to the mission rather than simply describe what level of automation will be used. The roles are 
Planning Assistant, Trajectory Manager, Systems Manager, Monitor, Back-up, and Team member. In 
general, these roles relate to the Palmer et al. definitions in the following way: Planning Assistant - Aid, 
Trajectory Manager - Augmenter, Systems Manager - Substitute, Monitor - Substitute, Back-up - 


28 



Substitute, and Team Member - Augmenter. 


6.2.1. Pilot 

The NFD strives to maintain and encourage essential aviation skills for the pilot. A pilot of an NFD 
equipped aircraft is expected to understand the fundamental factors of flight and airspace operations and 
to be proficient in their use and application. The pilot must be an active part of the aircraft’s operation 
and must have the knowledge, information, and authority to be responsible for the aircraft. This makes 
design difficult when an equally important goal is ease of use. If the normal operations of the vehicle are 
extremely simple (e.g., the pilot says, “Take me to my Grandmother’s house.”), the pilot will not be able 
to intelligently respond should something go wrong. The pilot may have learned the fundamentals of 
flight in order to get his pilot’s license but that knowledge is likely to atrophy if not routinely used. How 
does a designer balance maintaining the pilot’s necessary skill set, while not requiring all pilots to be part 
of the elite few with the ‘right stuff? The answer is to explicitly state the roles and responsibilities for 
the pilot and then design to support those roles and automate functions that do not support those roles. In 
the case of the NFD, the following roles were selected. 


6.2. 1 . 1 . Mission director 

In general, the mission means safely getting people and/or cargo from point A to point B within certain 
time, cost and comfort constraints. Therefore, in the role of mission director, the pilot needs to monitor 
these constraints and influence them. In general this means observing the mission level attributes of the 
flight such as time, fuel, location, expected time of arrival, etc. However, other factors can impact the 
successful completion of the mission even though they might be considered systems (engine performance, 
electrical load, etc.) or trajectory (lift, drag, thrust, heading, track, etc.) attributes. The mission director 
must be aware of these factors even if he is not able to do anything about them because they can affect the 
quality of his mission decisions. For example, degraded engine performance because of a fouled spark 
plug might lead to a different mission response than degraded engine performance due to low oil pressure. 

A large part of directing a mission is monitoring the progress of the mission. Because diligent monitoring 
is not a human forte, the machine should not just allow but must actively encourage the human to monitor 
these factors. Often, designers assume that since the information is available to the pilot that the 
monitoring requirement is fulfilled. However, human pilots can easily become complacent when 
monitoring highly reliable systems or for infrequent events (Parasuraman et al., 1996). A possible 
approach is to call on the pilot to perform a task that requires that the pilot use certain information. This 
requires the machine to know what the correct response should be and then have access to the sensor and 
situational data from which to make a comparison. The machine must constantly monitor that data and 
alert the pilot when there is a discrepancy. Such discrepancy information is extremely valuable in the 
pilot’s decision-making process (Klein et al., 1993). 


6.2. 1.2. Troubleshooter 

One of the primary roles for the human in a highly reliable system is to troubleshoot when things go 
wrong. The human has a unique abilities not found in computers. Humans “are excellent detectors of 
signals in the midst of noise, they can reason effectively in the face of uncertainty, and they are capable of 
abstraction and conceptual organization,” (Billings, 1997). These abilities are especially important when 
something has gone wrong or is simply unusual. Humans are better equipped than automation at dealing 
with the unexpected or unanticipated. But the fact that humans are better at troubleshooting than 
automation does not imply that they are especially good at it. They require a great deal of support. In 
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order to deal with the unexpected in a timely manner, they must be aware of the situation. If they are in a 
highly reliable, highly automated, and preprogrammed environment, they are more likely to be ‘out of the 
loop’ or complacent when an abnormality occurs. This situation sets the human up for failure at the 
troubleshooting task. The human must be engaged in the mission at all times and the best way to insure 
that is to provide active involvement in the mission. 

In order to effectively troubleshoot, the human pilot needs to evaluate the outcome of any responses to an 
abnormality. This can require that the human track a number of variables and constraints. These 
variables and constraints may be interdependent and their interactions may be complex. Humans have 
difficulty in mentally tracking all of these variables and interdependencies. Humans should be aided 
(ranging from memory aids to simulation environments that can test theories and responses) to maintain 
this information and to determine the consequences of any proposed response. 

Since the situation that the human will probably encounter in the course of troubleshooting will likely be 
unanticipated, it is important that the human be trained regarding how to troubleshoot. This training will 
likely involve meta-procedures (i.e., what to do when there are no written procedures applicable to the 
current situation) that describe methods for troubleshooting rather than specific steps. For low-time or 
low training pilots, troubleshooting assistance may be provided on-line. However, the on-line 
troubleshooter will have to be able to quickly immerse themselves in the mission. 


6.2. 1.3. Back-up 

In the case of some automation failure or even a mechanical failure, the human pilot may be called upon 
to perform a duty normally performed by the machine. For example, automatic communications may not 
be functioning and the human would have to communicate with airspace and ground services using voice 
radio. Similarly, the flight planning automation may not be functioning and the human must take on the 
responsibilities for planning, replanning and monitoring the flight plan. In rare cases, there may be 
‘manual reversion’ mode where the human must take over some more mechanical duty normally 
performed by the automation. For example, the pilot may have to manually lower the gear, or may have 
to control the trajectory of the aircraft without automation assistance. 

These events will most likely be very rare - a pilot may see such an event only once in their lifetime. The 
pilot should not be expected to maintain information and proficiency in these back-up roles. They should 
either be reinforced by training or by what Billings refers to as Information and Management Automation 
(Billings, 1997). That is, there should be salient, accessible, and intuitive resources that aid the pilot in 
remembering how to perform the back up duty. 

In addition, because the pilot’s workload has increased when they perform this back-up duty, the system 
should provide additional monitoring and assistance for the normal duties of the pilot. The pilot may 
become engaged in the backup duty to the neglect of a normal task such as mission director. The design 
should support the pilot in the role of mission director, even if it means that the pilot may become less 
involved in the direction of the mission. It is in these conditions that the automation is used more 
extensively. 


6.2. 1.4. Team member 

The pilot must cooperate with the automation. Cooperation requires communication skills and conflict 
management skills. The pilot must know how to communicate his intent to the automation and must be 
able to evaluate the automation’s intent (i.e., Norman’s Gulfs of Execution and Evaluation (Norman & 
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Draper, 1986)). The pilot needs to be able to monitor the automation^ performance. This is a 
particularly difficult problem in that the pilot must monitor the automation without the assistance of the 
automation, since that assistance may be the part of the automation that is defective. The only way to 
help the pilot perform this monitoring/cross-checking task is to make the intentions and the performance 
of the automation extremely noticeable and obvious. 

In some cases, the assessment or intent of the pilot may conflict with the assessment or intent of the 
automation. A general design principle that is commonly used is always to defer to the judgment of the 
pilot. However, if the pilot has not been given sufficient information and sufficient engagement in that 
information, the pilot may default to the judgment of the automation - thus losing the value of the pilot’s 
intelligence. One way of addressing this problem is to foster and encourage collaboration between human 
and machine. The idea is that the more that they work together, the more acquainted the human will be 
with the performance of the machine. It may even be possible for the machine to adapt to the human over 
time - to learn routines and patterns of a particular pilot’s behavior. 


6. 2. 1.5. Occupant 

The pilot is not a machine and cannot be treated as such. There are obvious considerations such as 
readability of displays, reach and strength issues, and allowing for eating and drinking, stretching, rest, 
and lavatory breaks. However, humans have other considerations that are often overlooked in design. 
Humans are prone to boredom, habituation, daydreaming, tunneling, complacency, over reliance, and 
curiosity. These are not errors or faults, but survival traits. They must be expected and accommodated. 
Humans require some sort of emotional ergonomics that makes the pilot feel relaxed, involved, important, 
and in control. This means that the pilot must be allowed some down time periodically and the he must 
be meaningfully involved in the task as opposed to busy work (Billings, 1997). 

6.2.2. Airplane & Automation 

The roles defined above for the pilot define the role of the automation. Put simply, the airplane must do 
everything necessary to maintain operational safety and efficiency that the pilot is not doing. The 
airplane is expected to do everything that the pilot isn’t expected to do or cannot do due to their finite 
resources. This creates non-traditional roles for the automation and perhaps more importantly, non- 
traditional certification requirements. For the NFD, one prominent change is to certify elements of the 
trajectory manager (i.e., the H-mode or autopilot features) to a higher level of reliability than autopilots 
are currently certified in modem commercial aircraft. This has been done in more limited applications (as 
in the case of CAT III-C autoland) so it does not require significant technological breakthroughs. 
Similarly, the automation must take on a more prominent role in checking that the aircraft and the mission 
are in compliance with airspace rules and regulations. In doing so, some liability will be transferred from 
the pilot to the manufacturer and to government authorities. This represents a major change in design, 
however given the goals of the NFD, it is simply unconscionable to demand that the pilot maintain such a 
huge database of information in their memory (the Federal Aviation Regulations / Airman’s Information 
Manual (FAR/AIM) alone consists of over 300 pages of regulations, procedures, and charts) or that they 
have to perform an exhaustive search of all applicable regulations before each flight. Therefore, much of 
the responsibility for insuring that a given plan is in compliance with quantitative legal requirements 
should be placed on the automation. In addition, the burden of informing the pilot of aspects of marginal 
or non-compliance is also placed on the automation. 
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6.2.2. 1. Planning Assistant 

The planning assistant is an information aid to the mission director. In the NFD, this is normally (but still 
remains a research issue) performed by the Integrated Trip Planner. The planning assistant performs the 
route calculations, optimizations, alternates and options that are legal 2 , feasible and safe. The planning 
assistant then creates a plan for the mission director to follow. This plan takes the form of a task list 
where each task is triggered by some event (e.g., time, location, configuration). The planning assistant 
notifies the pilot when those tasks are eminent, due, and past due. The pilot can modify that plan and the 
planning assistant will continue to assure that it is legal, feasible and safe. The planning assistant can be 
used to record non-trajectory related tasks (e.g., communication tasks). The plan, once created and 
checked, can be electronically communicated to the Actual system to be used as guidance (not control). 

The planning assistant also monitors the status of the plan during flight, to identify when there has been a 
significant change (e.g., a weather cell moving faster than predicted, an airport closure, a new temporary 
flight restriction) and alerts the pilot to this change as a potential need to replan. The assistant then 
provides alternatives to the pilot or allows the pilot to create his own. 


6.2.2. 2. Trajectory Manager 

In general, the trajectory manager is responsible for the safe and successful accomplishment of short-term 
tactical maneuvers. This usually means holding the aircraft on the current trajectory, preparing for the 
next change in trajectory, accomplishing that change, and establishing a new trajectory. In some cases, 
the change from one trajectory to another is complex or requires many configuration changes (e.g., flaps, 
gear, engine adjustments) over a short period of time, such as landing, takeoff, and flying a holding 
pattern in the air. In these cases, the trajectory manager may have to accomplish many trajectory changes 
rapidly. These patterns of complex trajectory changes are chunked into a single command called a 
behavior. The Trajectory Manager carries the primary responsibilities for the successful short-term 
(tactical) planning, assessment and execution of aircraft trajectory segments. These trajectory segments 
can be pieced together by the mission director (the pilot) to complete the mission. The automation will be 
responsible for smooth transitions where possible between segments. The trajectory manager must be 
highly skilled at performing maneuvers and must be able to react quickly to threats. This requires a 
thorough awareness of the immediate environment. 

The trajectory manager must monitor the environment at a high frequency. Air data, position data (e.g., 
inertial reference system, global positioning information), radar, ADS-B, machine vision, weather 
information and any other available information can potentially be useful to the trajectory manager. In 
the Naturalistic Flight Deck Concept, the trajectory manager is implemented using the H-metaphor. Just 
as a horse can negotiate terrain and implement the high-level commands from the rider, the H-mode as 
trajectory manager can implement the commands provided by the pilot as mission director. 

The trajectory manager accepts goals from the mission director and translates them into trajectory goals 
that are then passed on to the systems manager. While the trajectory manager does not ‘know’ how the 
systems work, it does know the capability of the systems in fulfilling trajectory goals. For example, it 
knows the maximum thrust that can be produced by the engines but doesn’t know whether the engine is a 
turbo jet or turboprop engine. After passing the goals down to the systems manager, the trajectory 
manager looks to determine if the goals are being achieved. If the trajectory manager cannot achieve the 


2 Legal here means that the planned route is in compliance with quantitatively defined regulations and airspace 
limitations. It is important to note that the plan is notional and in no way guarantees that the pilot must adhere to it. 
Thus the pilot can violate the plan and potentially perform an illegal action. 
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goals that the mission director has set for it, then it must notify the mission director that the goals cannot 
be met and provide explanations and alternatives. 


6. 2.2. 3. Systems Manager 

Systems on modem aircraft are extremely complex. Many systems are interconnected and this further 
adds to the complexity. It is highly unlikely that the human can maintain an understanding of how the 
aircraft systems work without providing a great deal of training to the human. In addition, there may be 
differences from aircraft to aircraft regarding how systems are implemented. It would be unreasonable to 
demand that the human understand these differences. 

The systems manager is responsible for configuring the aircraft systems to support both the trajectory and 
mission requirements. It must monitor the performance of the systems and determine when there is an 
abnormality or disparity between how they are performing and how they are expected to perform. This 
requires that the systems manager have a reasonable model of the normal operation of the aircraft 
systems. The systems manager must also be able to translate commands and goals from the mission 
director and the trajectory manager into systems and configuration commands. Similarly, the systems 
manager must be able to translate the impact of system configurations and malfunctions to the trajectory 
managers and mission directors in terms of their goals and objectives. 

The systems manager must be able to describe the operation and the interconnections of the aircraft 
systems to the pilot in real-time, should the pilot have to troubleshoot or intervene (taking corrective 
action or acting as a back up.) The systems manager should make it very plain as to where the pilot can 
intervene. 


6. 2.2. 4. Monitor 

Humans simply are not good monitors of highly reliable systems or infrequent events. They become 
complacent and can become less sensitive to true signals over time. Machines do not suffer from this 
flaw and therefore a majority of the monitoring responsibility is placed on the machine. The machine 
monitors the environment, the progress of the mission, the legality and feasibility of the mission, the state 
of the aircraft, and the state of the crew. The automation monitors for both mission effectiveness and 
efficiency as well as for safety. In general, if the monitor detects an abnormality that will affect the 
mission, trajectory, or systems effectiveness, the respective manager (i.e., mission, trajectory, or systems) 
will be notified. If safety is threatened by an abnormality, then the human is notified as well as the 
manager. In some cases, the Back-up may be engaged. 


6. 2.2. 5. Back-up 

The back-up role for the automation has two flavors. The first is a safety back-up. The safety back up is 
engaged if the automation determines that the human is not fulfilling (or violating) his role as mission 
director and jeopardizing the safety of the vehicle. An example of this is when the H-mode determines 
that the human is incapacitated and then aborts the mission per se and pursues a safe state (e.g., landing at 
the nearest suitable airport). The second form of back-up occurs when the human is called upon to 
perform a trajectory or systems related task (e.g., when he has to act as back-up). In these cases, the 
automation should attempt to perform some part or all of the duties that the human is now neglecting. For 
example, suppose that the pilot has to perform navigation duties normally performed by the planning 
assistant. If the pilot is normally responsible for initiating commands to the trajectory system based on 
the flight plan, the trajectory system may execute these commands by itself with permission from the 
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pilot. The trajectory system would notify the pilot that it was doing so and offer ample to opportunity for 
the human to intervene. 


6. 2.2. 6. Team member 

Automation is often described as the strong silent type (Woods, 1996). It does what it does and rarely 
informs the crew of why or sometimes even what it is doing. Such automation does not make for a good 
team member. In the naturalistic flight deck, the automation must be more revealing. It must let the pilot 
know when it is approaching its limits. If the pilot requests it to do something that it either cannot do or 
infers is unwise to do, the automation must be able to explain why and provide options for achieving the 
higher level goal of the pilot. The automation should be required to understand the pilot’s vocabulary 
(not necessarily natural language) and must communicate in terms of the pilot’s goals rather than the 
machine’s operation. Another way of describing this is that the pilot should not have to know how to 
program the computer. The pilot should just know how to achieve the mission. Then the machine must 
be able to state its intentions, status, and prognosis in terms that the pilot will understand, rather than 
make the pilot translate from the machine status to mission goals. 

6.3. Actual System 

As described in chapter 5, the Actual system provides access to information and control functions relevant 
to the immediate flight situation and actions of the aircraft. The “time horizon” of information needed to 
assess the immediate situation should generally project far enough out to assess factors that might 
necessitate or constrain temporary deviations from the nominal route (e.g., local traffic, weather, terrain, 
aircraft health/status), any imminent pre-planned high-level changes in the route, and potential, urgent 
contingencies such as a forced landing or escape routes if operating in conditions conducive to hazardous 
weather (e.g., icing, thunderstorms). Through the Actual System, the pilot should be able to efficiently 
assess and implement any tactical air traffic control (ATC) directives or perform self-separation as 
appropriate. There are several key elements that allow the Actual system to perform reliably, predictably, 
and efficiently. The major subsystems within the Actual System relate to the automation implementing 
horse-like transportation capability and interaction, robust task management and alerting, autonomic 
systems management, and communications. These elements are described below. 

6.3.1. H-system: 

The H-system, the physical realization of the H-metaphor in the NFD, is shown conceptually in figure 8. 
The H-system can perform complex behaviors such as trajectory following, landings, take-offs, and 
holding patterns as a single behavioral entity. For example, the pilot can direct the aircraft to land on a 
particular runway and it will take care of lining up on the runway and maintaining proper glide slope. 
While the H is performing these behaviors, the pilot can continuously control key parameters such the 
runway aim point of the approach path. Using real-time and stored information (e.g., terrain, airspace 
databases), the H-system formulates an assessment of the current situation using a simple, object-oriented 
model structure accommodating the common factors of flight including weather, terrain, traffic, airspace 
elements, own ship performance, and pilot directives. In this formulation, the H identifies hazards that 
must be avoided, lesser conflicts that should be resolved and positive features that it should move toward 
like the nominal route from the Notional System or a runway designated by the pilot. The H-system 
develops a nominal course of action including a flight path based on this assessment. The general 
priorities in developing this course of action reflect: 1. Self-preservation, 2. Any real-time directions from 
the pilot, 3. Satisfying regulatory requirements, and 4. Following nominal route segments from the 
Notional system. The pilot is able to intuitively observe and influence the H’s situation assessment and 
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action formulation process through the H-mode interface element, described in more detail below. The 
interface also allows the pilot to easily override these processes if desired or if required, for example, in 
response to erroneous information. 


Conceptual System Diagram for Aviation Application 
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Figure 8: H-inspired flight control system 

The pilot manages the vehicle’s trajectory and maneuver behaviors through the H-mode interface system. 
The generic interaction characteristics of the H-mode are compared to conventionally automated vehicles 
and non-automated vehicles in table 3. The H-mode characteristics should support more natural 
communication between the pilot and automation. The implementation concept includes a synthetic- 
vision based primary flight display (PFD), a tactical navigation display (TND), two-way auditory 
communication, and the haptic side-stick and speed command lever (not shown in figure 8). 
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Vehicle class 

Characteristics of 
the interaction 

Conventional vehicle 

(w/o control 
automation, e.g. 20 th 
century car without 
cruise control) 

Conventionally 
automated vehicle 

(e.g. 20 th cenUuy 
commercial aircraft) 

Horse / H-inspired vehicle 

Direction 

Mainly unidirectional 

Mainly unidirectional, 
some bi-directional 

Mainly bi-directional 

Coding 

Analog / spatial 

Mostly linguistic /abstract 
Some analog / spatial 

Mostly analog /spatial. 
Some linguistic /abstract 

Modality 

Multimodal with haptic 
component 

Strong visual component, 
some multimodal aspects 

Multimodal with strong 
haptic component 

Discrete or 
continuous? 

Mostly continuous 
input 

More discrete input and 
output 

Mix of continuous and 
discrete input / output 

Importance of 
visual modality for 
the guidance task 

High 

High 

Medium 

Redundancy in the 
interaction 

Low 

Medium 

High 

Negotiation of 
different wills 

None 

Non-oven, brittle, 
"either / or" (automation 
will is more implicit) 

Transparent, fluid 
("automation" will is 
explicit) 

Who is in the 
physical loop, 
human and 
automation? 

Human (automation 
only in low' level 
functions, e.g. a 
governor in a car) 

Exclusive either/or for 
specific axes 

"Automation" and human 
are in the loop 
simultaneously 


Table 3 : Comparison of H-inspired vehicles to more traditional vehicles 


The haptic modality provides the primary link between the pilot and flight control automation. Both the 
pilot and the higher-level functions of the H control the path of the airplane through the haptic interface 
devices. The position outputs of these devices are the inputs to an inner-loop stability and control 
augmentations system (SCAS). The SCAS provides a velocity-vector based response type with 
integrated flight envelope protection and is analogous to a horse’s cerebellum and neuromuscular 
systems, providing an interface between higher-level, cognitive processes and low-level sensors and 
actuators. The SCAS provides both the pilot and the higher-level functions of the H, with simple, direct 
control over the immediate motions of the airplane. With the other, higher functions of the H disabled, 
the feel characteristics of the stick and response of the airplane are identical to current fly-by-wire aircraft 
with a velocity-vector based response type such as described by Duerksen (2003). The H also 
implements its higher-level behaviors by moving these same devices. The H accomplishes this by 
commanding their zero-force or trim positions. If for example, the H is following a trajectory segment, 
the path steering function will manipulate the stick position such that the airplane captures and tracks the 
desired path. The pilot can feel the actions of the H by lightly holding onto the controls. If the pilot 
applies a force to the stick while the H is maneuvering, the stick position will move from its zero-force 
position by an amount dependent on its feel characteristics such as the break-out forces and centering 
gradient. The H’s interaction manager monitors the pilot’s forces and uses this information, combined 
with its overall situation assessment to determine short-term directives from the pilot and adjusts its 
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actions in accordance with these directives. The interaction manager also can adjust the force-feel 
characteristics of the controls so that the pilot can feel limits or reservations that the H may have in 
responding. In addition to these low-frequency, continuous force signals, both the pilot and H can send 
and receive high-frequency, “language” elements via the haptic controls. These elements include a 
simple but flexible set of shakes and pulses that enable basic communication of discrete commands and 
signals to be communicated. 

The combination of continuous and discrete language elements allow the human and H to be “in-the- 
loop” simultaneously and as shown in figure 9, fluidly exchange roles as leader and follower as needed or 
desired. When the H has the lead, the situation is termed “loose reins” and the H typically has a well- 
defined behavior such as following a procedure, taking-off or landing. The pilot’s hand rides lightly on 
the controls and can provide gentle cues that modify the H’s performance within the current behavior. 
Example modifications would be tracking slightly above the glideslope or to the left of a centerline, 
following traffic with closer than nominal separation, or landing long. In “tight reins”, the pilot has the 
lead and H minimizes its use of cues except as needed to support hazard awareness/avoidance or facilitate 
haptic communication. 



H-vehicle 
requests (initiates) 
transitions 


Figure 9: Potential transitions in an H-Mode 

The two visual displays provide graphically intuitive representations of the external environment overlaid 
by basic flight parameters and the H’s interpretation of this information. Since the H performs the inner- 
loop, attitude stabilization and control functions, the presentation of flight parameters can be significantly 
simpler than current displays. The environmental information includes physical elements such as terrain, 
weather, and traffic and virtual elements such as airspace boundaries and published fixes, routes, and 
procedures. The route from the Notional system, if present, is also included. Symbology specific to the 
H includes the H’s situation representation, the “H-path” and the H’s center of attention (H-coa). The H’s 
situation representation provides a picture of how the H perceives the external environment. This 
presentation allows a pilot to quickly ascertain what the H is responding to, how these influences are 
shaping its actions and how it would respond to inputs from the pilot. The H-path represents the path that 
the H will follow on its own without further short-term, pilot inputs. The H-coa allows the pilot to 
graphically program the H to perform multi-step behaviors such as flying to a fix or intercepting a 
procedure. The H-coa is a narrow cone around the aircraft’s current velocity vector and appears as a 
circular reticle on the perspective display and a beam emanating from the nose of the own ship symbol on 
the map display. When the pilot maneuvers the airplane such that a fix or route is steadied (or aimed) 
within the H-coa symbol, the H highlights the feature and generates a list of situationally appropriate 
actions. If the pilot accepts one of the actions, it becomes active and the H can transition to loose-reins. 
While this sounds complex, in operation it’s quite natural. For example, to change between parallel 
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approach procedures, the pilot simple uses the stick to maneuver the airplane toward the parallel 
procedure depicted on the displays. The H displays a proposed path that intercepts the procedure. By 
accepting this path, the change is complete. In addition to this “point to program” capability, the pilot can 
also couple the automation to a route or procedure by simply flying the plane into position and alignment 
with the desired procedure as shown on the visual displays. The auditory interface features will 
compliment the haptic and visual elements. In keeping with the H-metaphor, these communications can 
be bi-directional but limited in content and complexity (e.g., not complex sentences). 

6.3.2. Task Management and Alerting: 

Another aspect of the Actual System and H-mode interface is a task management and alerting capability. 
Human memory (both retrospective and prospective) is a volatile and unpredictable part of human 
behavior. Because the pilot is required to be more engaged in the mission in the NFD, there is a potential 
for errors due to human memory problems (e.g., forgetting to level off at a certain altitude, forgetting to 
contact ATC, forgetting to reconfigure systems). The concept of complemation calls for the automation 
to assist the human in dealing with these problems. As part of the Actual system, the pilot will receive 
visual, haptic and auditory cues that prepare them for these actions and as well as recommend or take 
corrective action if an oversight takes place. Clearly the design of this capability must address 
complacency concerns to ensure that the pilot does not become reliant on this capability for routine 
operations. The intent of the system is to encourage the pilot to function as an independent agent, not a 
‘meat-servo’ that only responds only to direct cues for action. In addition, the design of this system must 
strive to eliminate nuisance alerts. 

The pilot may only be able to concentrate on one task at a time and is likely to become absorbed in a task 
to the neglect of other monitoring duties. While this concentration is appropriate for problem solving and 
resolution, it is inappropriate for monitoring the situation of the aircraft (Schutte & Trujillo, 1996). 
Rather than have the pilot switch attention for the monitoring task, the system can provide mission status 
in the pilot’s ‘periphery’. The NFD will use concepts such as Mission Status Graphics (Trujillo, 2002) 
and ubiquitous, ambient cues such as background sound and display border coloring to provide situation 
awareness to the crew while concentrating on a particular task. 

6.3.3. Autonomic Systems Management: 

In general, most of the systems management on board the aircraft will be performed by the automation. 
Details and complexities of the hardware and design are often too difficult for the average and infrequent 
pilot to hold in their mind for long periods of time. In addition, most configuration changes (e.g., gear 
and flap deployment) are handled automatically by the machine. However, this does not mean that the 
information about the system’s performance is kept from the pilot. Rather, system status, diagnosis, and 
prognosis information is presented to the pilot along with their consequences on the mission of the 
aircraft. Even if the pilot cannot affect the system in any way, the information can help the pilot make 
informed decisions regarding the mission (such as whether to divert to an alternate, whether to choose one 
alternate over another). 

Systems management also encompasses the human and the automation. These two represent the 
intelligence of the mission and are crucial to its safety and success. Human monitoring has been briefly 
touched on in the discussion of the H-mode above. But more elaborate monitoring of the human may 
take place as technology improves. For example, blood alcohol levels, blood sugar levels, brain activity, 
etc. If the human is suffering from low blood oxygen or blood sugar, their decision-making ability could 
be impaired. In addition, the automation must be monitored. Monitoring the automation should be 
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delegated to the pilot because he is the most obvious agent to perform crosschecking. However, humans 
are poor long term monitors of highly reliable equipment. Therefore the automation must not only be 
designed to fail safe but also to fail loud so that the pilot is aware of its failure. Of course, one of the 
major dangers is the subtle automation failure, one that can easily go undetected. It is important for the 
automation to provide the pilot with some status of its own activities and health if possible. The pilot will 
need to be trained to detect abnormalities in this information. If the automation has failed and that failure 
is not obvious to the pilot, it most likely will be overlooked. 

6.3.4. Communication: 

Another crucial part performed by the Actual System is communicating data with multiple and various 
sources of information. The formats of these sources may be digital or verbal. The system must have an 
internal data format that allows it to integrate information but must be able to interpret ATIS, NOTAM, 
PIREP, NEXRAD, and other such data and translate it into the form useable by other elements of the 
system such as the H-system and the Notional System. The format and the data available may be location 
dependent (for example, in Asia or Latin America). The communications element must be able to handle 
these data types as well, or know the boundaries of the area in which it can operate. Finally, the 
communication system will be able to transmit information to other information services, for example, to 
file a flight plan with the local airspace authorities, or to request facilities at the destination airport. The 
origin of this information may be from other system segments such as the H-system. 

A key challenge in the near term is assisting the pilot with voice based ATC interactions. While voice 
communication may, at some point in the future, be completely replaced by data link for all routine ATC 
exchanges, this transition is likely to be slow and the reality of voice communication must be recognized. 
Voice communication raises two related issues. The first is correctly receiving and sending clearances 
and clearance requests. The second is entering the clearance into the automation. The NFD will provide 
ground to aircraft communications in a consistent, redundant presentation of information. If the 
information is transmitted by datalink, then the system will present the text information to the pilot. In 
addition to this text information, a voice synthesis program will speak the information to the pilot if the 
pilot so chooses. Conversely, if the information from the ground is transmitted over voice channels, a 
speech recognition system will attempt to recognize that information and provide it in a text format as 
well. So in all cases, the pilot has the option of either hearing the information or seeing the information or 
both. There are several advantages to this approach. The first is that humans understand and remember 
information that is presented both visually and aurally together better than either medium alone. Second, 
it provides a consistency in whatever airspace the pilot may be flying. Third, it allows a mechanism for 
the pilot to double check the automation’s understanding of information. In addition to these features, the 
communications system will record voice communications so that the pilot can replay a voice message 
rather than requesting the ground to ‘say again,’ if the pilot didn’t catch the message. 

6.4. Notional System 

The Notional components of the flight deck are not flight critical, that is, the aircraft can be flown without 
them. However, they allow the pilot to better prepare for the mission and to handle contingencies. The 
pilot can use the Notional system to plan the mission, plan contingencies, review plans, rehearse mission 
elements, explore potential outcomes, and predict future weather and traffic patterns. The key component 
of the Notional system is the Interactive Trip Planner. 
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6.4.1. Interactive Trip Planner 


The Interactive Trip Planner or ITP provides complemation for the Notional aspect of the mission. The 
ITP is a portable device (perhaps a tablet PC or PDA) that can be used for intelligent planning of 
missions. The pilot can develop a flight plan, alternates, plan tasks, play out ‘what-if scenarios and even 
simulate a flight using the ITP. The ITP can check on legal requirements and insure that the pilot is 
aware of what requirements need to be met. The ITP can assist the pilot in reviewing or rehearsing tasks. 
The ITP may even set up the mission by electronically filing a flight plan or detecting that certain 
equipment is available (e.g., making reservations or requests at ground facilities). The ITP either can be 
carried on to the aircraft and installed on the instrument panel or it can communicate its information to a 
mirror ITP permanently installed in the aircraft. 

The ITP is extremely memory intensive and dependent. While it will rely on external sources of 
information, it needs to maintain a great deal of data in order to form a robust description of the situation 
and the rules and procedures appropriate to that situation. This includes (but not limited to) terrain 
information, airport information, airport and airspace procedures, communications protocols, regulatory 
rules and requirements, aircraft information and procedures, and pilot information and limitations. 

The ITP will generally communicate with the pilot in a human-like fashion, accepting complex 
instructions, requesting clarifying information, inferring missing information, and reasoning in an 
integrated fashion (big picture) using mission goals and sub-goals. The primary function of the ITP is the 
planner. 


6. 4. 1.1. Planner 

The pilot creates a mission plan using the ITP. He inputs or selects the critical criteria of the flight such 
as the origin, destination, aircraft, and time and date requirements. The planner then constructs a number 
of legal routes that satisfies those criteria. These routes can vary in terms of cost, duration, 
complexity/difficulty, or risk. The pilot can select from among these routes. The pilot can then modify 
the route plan using a number of interface tools (object manipulation, voice, keyboard, multiple choice). 
In general, the ITP will insure that the pilot can only create a legal route, and will prevent him from 
making an illegal modification 3 . The ITP will query various information sources to determine current and 
predicted conditions (e.g., special airport procedures, special use airspace, traffic and weather) and will 
adjust the plan accordingly. 

The ITP will create plans for alternates and will compute the fuel required for the route. It determines 
compliance with the minimum equipment list (MEL) and the desired configuration list (DCL) for the 
mission. The ITP will create a plan for the pilot to alert him to changes in the velocity vector or the 
behavior of the aircraft. This plan will be used by the Actual system to provide guidance and alerting to 
the pilot and the H system. The pilot may add alerts to the plan based on time, location, or event (e.g., 
Notify me when fuel quantity is less than . . .). 


6. 4. 1.2. Simulator 

The ITP contains a robust simulator of the aircraft and the geographic and weather environments. This 
simulator serves two purposes. The first is to validate plans created by the ITP to insure that they are 

3 There may be conditions where the pilot is allowed to make illegal modifications, but these 
should be rare and the pilot will be prominently and sufficiently alerted. 
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feasible. The second is to allow the pilot to train, rehearse and review certain aspects of the flight and to 
explore different options in a benign environment before committing to one in the Actual system. 

Out of the aircraft, the pilot could connect inceptors and displays to create a low cost simulator to use for 
training. It is not uncommon for pilots to test and explore systems and ideas in flight because they have 
no way of doing so anywhere else. This, of course, may be unpredictable or even dangerous. The 
simulator in the ITP could provide this benign sandbox for the pilot to explore the options of his aircraft. 
In addition, the pilot could explore what would happen in the case of certain failures and practice 
responding to these failures. This would enhance recurrent training, which would reduce the cost of 
operation of the aircraft. 

7. Operational Scenarios 

This section is an attempt to ‘flesh-out’ the components described above. It is important for the reader to 
remember that any details in this section should not be considered to be design decisions but rather 
speculations on the part of the authors. A host of research questions will need to be addressed before the 
final NFD design can be described at this level of detail. The final design may not look or function like 
this description at all. Indeed, some of the details described below may not be feasible. 

7.1. Normal Operations 

This scenario describes a nominal trip taken by the pilot. The pilot decides to make a trip from X to Y. 
He pulls out his ITP and begins a new trip plan. He selects X, Y, the time, date, and the airplane he wants 
to use. The ITP then performs several operations. It checks the availability and the status of the aircraft. 
It creates three different safe and valid routes. One route is the shortest time, the second is the lowest 
cost, and the third is the most comfortable (e.g., extremely risk aversive, avoiding any potential bumpy 
rides or congestion, easy to fly). The pilot can pick from other route qualifications such as ‘scenic’ or the 
pilot can open a previously saved route. 

The pilot then enters the route review and modification mode on the ITP and reviews the routes that the 
ITP has generated and picks one of them. He can then modify the route using direct object manipulation, 
however he cannot modify the route in such a way as to make it invalid or unsafe or incomplete. If he 
tries to do so the ITP informs him of the reason he cannot modify it as he wishes and what else he would 
have to change if he wanted to make that modification. For example, if the pilot tries to add a waypoint 
on the route that is out of range of the aircraft’s currently fueled range, he will not be allowed to do so - 
however, the ITP will suggest ways to add that waypoint such as adding fuel, using an aircraft with a 
different range specification, or landing along the way to refuel. The pilot can make quantitative 
adjustments (using digit wheels, keyboard or voice input) on each quantitative piece of data (e.g., altitude, 
airspeed). 

Once the route is selected and modified, the ITP generates alternates for that route and a pilot task plan. 
If the ITP has a pilot’s log feature, it may compare the regulatory requirements for flying the mission with 
the capabilities and qualifications of both the aircraft and the pilot. If the pilot has flown the route before 
and the ITP detects changes from that previous route (e.g., different procedures at the destination airport), 
the ITP can alert the pilot to those differences. 

The pilot can then review the details of the route using the ITP. He can do so in a number of ways. The 
most basic is simply a plan and profile view that allows the pilot to skip from waypoint to waypoint along 
the route, with each waypoint displaying the pertinent mission data (e.g., time, altitude, airspeed, fuel). 
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Another option is to set up the ITP to show the primary flight displays (e.g., perspective, plan, profile) 
and perform a fast-time simulation of the planned flight. This simulation would be performed according 
to the plan without pilot input - that is, the simulation would simply be ‘playing’ the planned flight. 
Another option might include connecting the ITP to additional displays and inceptors and allowing the 
pilot to practice flying the route. For any of these options the pilot can select to review only certain 
portions (e.g., landing). 

The ITP is capable of filing the flight plan with the appropriate airspace management authorities and will 
do so on pilot request. 

The pilot then carries the ITP to the aircraft. The ITP presents checklists for preflighting the aircraft. The 
pilot then installs the ITP in the aircraft and it communicates the intended mission with the rest of the 
aircraft systems. All aspects of the flight (e.g., schedule, current weather forecasts, tasks) are loaded onto 
a shared information database (located in the Actual system.) The pilot initiates an engine start and the 
aircraft emits an engine start signal to warn anyone in the proximity of the starting engine. While starting 
the engine, the aircraft requests permission to start the mission from the authorities. Once cleared, the 
Pathway displays (e.g., perspective, plan display, profile displays and any HUDs, canopy displays, or 
other conformal visual displays) show the cleared guidance path. 

■ A Guidance Path consists of five display elements. They are a tube (visible only outside the tube), 
centerlines (floor and ceiling if in air, floor only if on ground), guardrails (one on either side of the 
path), speed rings (where spacing between rings denotes speed), and pace rings (additional cues to 
provide a natural depiction of the speed - pace rings travel along the path at the guidance speed). All 
these elements are relative to the inertial path, not the aircraft. Thus, if the aircraft were to be banked 
at 90 degrees, the guardrails will be on the top and bottom from the pilot’s perspective. 

■ A tube is semi-transparent with a shading of either yellow or magenta. A yellow tube is a published 
route or pathway that is not in the current mission plan. A magenta tube is part of the mission plan (it 
does not matter whether it is published or not). Tube radii are generally some function of the 
wingspan of the aircraft (3 or 4 times). Thus the aircraft can fly inside a tube. Flowever, tubes are 
invisible when inside them in order to avoid unnecessarily tinting the information on the Path display. 
Thus the pilot can see a tube when he is outside of it as a reference of a path to fly to. Flowever, once 
inside the tube, the pilot can depend on centerlines and guard rails for directional guidance. 

■ Guardrails are long narrow cylinders that run on either side of the tube (90 degrees from the 
centerlines). Guardrails serve to provide additional boundary cues for directing the path of the 
aircraft. In addition, the color of the guardrail is an indicator of the type of path. A magenta guardrail 
indicates the ITP selected path. Yellow guardrails indicate a published path (e.g., jetway, approach to 
another runway). Guardrails are visible both inside and outside the tube. 

■ Centerlines are thick lines drawn on the top and bottom of the tube. Centerlines can be green, 
yellow, or red. A green centerline represents that the aircraft is cleared to follow the path and that it 
is safe to do so. A red centerline indicates that the aircraft is either not cleared or it is not safe to 
follow the path. A yellow centerline indicates that the pilot is on a route that does not require a 
clearance - that is, it is a published or planned path that the pilot can fly at his discretion. Note that in 
these cases, the pilot (and aircraft) will probably be responsible for self-separation and see-and-avoid. 
Also note that if the pilot is flying on a published path, that is not a planned mission path (yellow 
guardrails) and in an airspace that does not require clearances (yellow centerlines) the pilot cannot use 
the rails and lines as redundant horizon indicators. Centerlines are visible both inside and outside the 
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tube. 


■ Speed rings are only present when there is speed guidance. Speed rings are narrow tori that band 
around the tubes at regularly spaced intervals. The spacing represents the distance covered in a unit 
of time (TBD) at that speed. Thus, the faster the speed, the further the space in between the rings. 
Speed rings are visible both inside and outside the tube. 

■ Pace rings, like speed rings, are only present when there is speed guidance. Additionally Pace rings 
are not present when a clearance is required and there is none (i.e., the centerline is red). Pace rings 
are tori similar to speed rings. The distance between Pace rings is based on some fixed length 
(perhaps related to the length of the aircraft). The Pace rings travel along the tube at the guidance 
speed. Thus, the pilot can try to ‘catch the ring’ and keep pace with it as an approximate indication of 
speed. To avoid clutter, pace rings become invisible when the aircraft is traveling at the proper speed. 

The desired speed is indicated both as a bug on the speed display but also as pace rings surrounding the 
path. When the aircraft appears to be moving at the same speed with these rings, he is at the prescribed 
velocity. The pilot controls direction and speed using the direction stick and the speed lever. Both are 
force feedback driven in order to provide two-way communicate between the aircraft and the pilot. While 
on the ground, the direction stick will only direct lateral movements (i.e., left and right). The pilot moves 
the speed lever and direction stick to command the aircraft down the desired taxiway towards the runway. 
The pilot is actually communicating with the ‘piloting’ portion of the aircraft (hereafter called the H). If 
the aircraft has not been cleared to move, there will be no green centerline or pace rings and the H will 
present slight resistance on the speed lever and will issue an objection (aural and/or visual). The pilot 
may still command the H to move and it will do so, but reluctantly. If the pilot stops issuing commands, 
the H will move the aircraft to a safe state. For example, if the pilot has commanded the aircraft to move 
before a clearance has been issued, the H will provide a slight resistance but move. The pilot will have to 
apply some pressure to keep the command engaged. If the pilot releases pressure, and if the H is in a safe 
spot on the taxiway, it will slow to a halt. However, if the pilot removes pressure and the aircraft is 
crossing a clear yet active runway for example, it will continue across the runway until it is safe on the 
other side. This is the basic behavior of the H. 

■ The H will move the aircraft at the pilot’s command without impedance if the command is for a safe 
(no threat based on criticality, general probability, and sensed danger) and legal (cleared with all 
authorities and according to airspace rules) maneuver. 

■ The H will move the aircraft at the pilot’s command with mild resistance on the stick and/or speed 
lever and with aural and/or visual objections if the command is for a safe but invalid (e.g., not 
cleared, violation of rules) maneuver. 

■ The H will move the aircraft at the pilot’s command with heavy resistance on direction stick and/or 
speed lever and with aural and visual warnings if the command is for an unsafe maneuver. 

If the aircraft is cleared and the H senses no danger it will obey the pilot’s commands to follow the 
cleared path. The pilot must make all ‘gross’ or high-level turn commands and speed commands. The H 
will achieve and maintain the aircraft direction and speed according to those commands and subject to the 
rules mentioned above. The H will alert the pilot aurally, visually and/or haptically when a planned turn 
or speed change is approaching. The H will provide a distinct alert when the turn or speed change should 
be executed. The H will provide a distinct warning when a turn or speed change has been missed. The H 
will not execute the turn or speed change (except under very special conditions to be discussed later and 
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with very specific consequences). 

■ The H will alert the pilot when a planned change in the velocity vector of the aircraft is approaching. 

■ The H will alert the pilot when a planned change in the velocity vector should be executed. 

■ The H will alert the pilot when a planned change in the velocity vector has been omitted. 

■ The pilot is responsible for commanding all high-level velocity vector changes. 

■ The H will not execute a planned change in the velocity vector (except under special circumstances). 

The pilot follows the cleared green centerline along the taxiway. If there is a hold point, the H will resist 
violating it (which means it will slow down and stop if the pilot does nothing at the hold.) The centerline 
ahead will no longer be marked with green but red instead. When the aircraft is cleared to continue, the 
centerline ahead will turn green and the pilot can command the H to move forward and the H will move 
the aircraft with no resistance. 

Eventually, the aircraft will approach the active runway for takeoff. When the aircraft may proceed onto 
the runway (e.g., cleared if the aiiport is towered), the pilot commands the turns for the aircraft to move 
into takeoff position. 

The pilot then initiates the takeoff behavior, causing the aircraft to take off. The pilot does not need to 
control the aircraft once the behavior has been initiated. 

■ Behaviors are a complex series of apropos aircraft control adjustments (thrust, lift, drag) and attitude 
adjustments (pitch, yaw, heading) that are performed by the H in response to a single command given 
by the pilot. Examples of behaviors are takeoff, land, path interception and following, performance 
maneuvers (e.g., best climb) and holding (entering and executing a holding pattern). Other potential 
behaviors are go-around, follow (another aircraft), emergency ditch, emergency force-land or a 
doglegged delay for meeting a 4D restriction. However, it is important to limit the number of 
behaviors to a set that is both memorable for the pilot and that is intuitively manageable. 

When performing the takeoff behavior the H will accelerate to takeoff speed, monitor for V 1 , rotate at 
VR, and climb at V2. The H senses the runway for obstructions or dangers and will avoid them if 
possible including aborting the takeoff before VR according to rules and procedures. The H will then 
climb the aircraft to a specific departure point. 

There are many potential implementations for the initiation of behaviors. Here are two potential 
implementations for the takeoff behavior: 

7.1.1. Implementation 1 

■ The pilot advances the speed lever to the maximum position. The maximum position is not up 
against the ‘firewall’ or full deflection but rather the maximum ground speed for the aircraft. 

■ The pilot pulls back on the direction stick full deflection. This does not cause the aircraft to pitch 
up because it is on the ground. If the aircraft meets requirements (e.g., MEL) and safe for 
takeoff, this act removes the max ground speed restriction. 

■ The pilot then pushes the speed lever to its maximum forward deflection while holding the 
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direction stick full back. 

These two full deflection inputs signal the H for a takeoff maneuver. The H signifies that it is performing 
the takeoff behavior and the pilot can let go of the speed lever and stick. 

7.1.2. Implementation 2 

■ The pilot advances the speed lever to the maximum position. The maximum position is not up 
against the ‘firewall’ or full deflection but rather the maximum ground speed for the aircraft. 

■ The pilot presses a dedicated switch on the direction stick that indicates takeoff. 

■ If the aircraft is safe and meets requirements for takeoff, these two inputs signal the H for a 
takeoff maneuver. The H signifies that it is performing the takeoff behavior and the pilot can let 
go of the speed lever and stick. 

The H takes the aircraft off and flies to the departure point that it was assigned. If the airport does not 
have published procedures the H simply flies to its ‘standard’ departure point or exiting condition. This 
point marks the end of the behavior. As the aircraft is approaching this point, the H alerts the pilot that he 
will have to command the velocity vector from this point. The departure procedure (assigned, published 
or H-standard) is presented to the pilot as guidance on the Path displays. The pilot is then responsible for 
making the velocity vector commands. If the pilot does not, the H will warn the pilot that the point has 
been missed and maintain the velocity vector it was holding at the departure point as long as it is safe to 
do so. If, for example, this velocity vector would move the aircraft into other traffic, the H will direct the 
aircraft to a safe vector. It may well be that the safest vector to turn to is indeed the first vector in the 
departure procedure. However, it is important to note that the H is NOT performing the mission 
departure procedure. It is performing its own safety maneuver, which in this case is coincident with the 
departure. However, several things are happening in the aircraft cockpit and in the reasoning logic of the 
H that are different from what would be happening if the pilot were commanding the aircraft to the 
mission departure path. The H is providing extremely clear and obtrusive warnings to the pilot in an 
attempt to have the pilot regain control. In addition, the H may be signaling control authorities of the 
pilot’s lack of input (this is a legal point). The H is also now considering that the pilot may be 
incapacitated. The H will look for confirming signs (or non-signs) to establish this. These signs are a 
design and research question but they might include detecting if the pilot makes the expected appropriate 
control inputs, detecting if the pilot makes any control inputs at all, having the pilot silence the warning 
using a combination of inputs (e.g., a keypad entry) or some combination of these 4 . 

The purpose of having the pilot make the inputs rather than simply having the H fly is to engage the pilot 
in a meaningful way without overwhelming him or requiring significant aviation skills. 

Normally, the Path displays will be presenting guidance in the form of magenta guidance paths. For the 
remainder of the flight, the H will alert the pilot to upcoming turns and/or speed changes and the pilot will 
command those changes using the direction stick and speed lever. The pilot commands the velocity 
vector by using the direction stick to point a command icon (the H-coa) on the path displays ‘into’ the 
tube of the next guidance path. Once in that tube, the H will maintain the velocity vector. The pilot and 
H continue to work together in this manner throughout the rest of the flight, if there are no changes to the 
path created by the ITP. If the pilot wishes to move to another vector or form of guidance, the pilot can 
simply point the H-coa at the guidance and the H will highlight it, in a sense asking the pilot if this is 


4 If the pilot is in a high workload tactical situation, it is likely that he will have a command input of some kind and 
that should silence the alert. If the pilot is entering a long leg and would not normally have to enter a command to 
silence the warning, he could then use the keypad since he has time. If this scheme were used, the pilot might find it 
easier to enter in a command input that was off the intended path (thus silencing the alarm) and then put the aircraft 
back on the path. However, a command off the path will signal a different alert and perhaps make a note in the log. 
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what he wants to do, the pilot can respond yes or not. If yes, then the H will proceed on the most efficient 
way to intercept the guidance. For example, if the pilot wants to fly to a certain lat/long (i.e., a waypole), 
he simply moves the direction stick until the H-coa is on the waypole. As the H-coa is close to the 
waypole, it will have a slight magnetic tug in the direction of the waypole as further indication that there 
is a valid target. The H will highlight this pole. The pilot can signal the H (perhaps through some 
discrete input on the direction stick) that this is the new target. When the H accepts the waypole as a 
target, it will then allow the pilot to make lateral changes and speed changes to lock on to a particular 
altitude on the pole and a particular time of arrival at that pole. Speed is displayed not only as airspeed 
but also as time to intercept the new target. 

On approach to the destination airport, the pilot will direct the aircraft to an arrival point within sight of 
the runway and at minimum decision altitude. When the H-coa highlights this point, the pilot will initiate 
a landing behavior. The H will then perform the landing (including flare and roll out). The pilot will then 
command the aircraft to the hanger, tie down area, or service area in the same manner used to taxi out at 
the beginning of the flight. 

Depending on the airspace management system and the weather, there is a chance that the pilot will have 
to deviate from the original plan provided by the ITP. If the change is to occur while on the current 
velocity vector and before the next commanded direction or speed change, the pilot can execute the 
change simply using the stick and power lever. If the change will take place beyond the next scheduled 
change and if the pilot has time, he can make that change in the trip using the ITP and this will be 
communicated to the aircraft plan. He can easily just wait for the aircraft to come to the changed vector 
and implement the change using the stick and lever. However, he will not have the reminder cueing and 
could potentially miss the change. 

There are several, potentially different goals that the pilot can have for deviating from the planned path. 
He can leave the planned path to join another published path. He can leave the path to fly to a new 
heading based on ATC commands. He can fly direct to a particular waypoint. He can fly to a new 
altitude. Another, more subtle deviation from the path is to change speed. 

To leave the current path to join another published path, the pilot must exit the tube. The H offers a 
slight resistance in the direction stick as if bumping up over a curve. The pilot can then point the velocity 
vector of his aircraft at the new tube path that he wants to join. When the H-coa crosses the intersection 
of the current velocity vector and the tube, it highlights the tube. If the pilot accepts the interception, the 
H plots a course for making a smooth turn into the new tube. The H will then treat this as the next turn in 
the guidance and will offer alerts for approaching the tube and for executing the turn onto the tube and if 
the turn is not executed. If the pilot does not turn onto the new tube path but instead crosses over it, he 
will feel the H bump the direction stick as if riding over railroad tracks. It the pilot does turn the vector 
onto the tube path; the H will produce a slight bump on entering the tube (as if dropping down off a curb) 
and will capture and hold the path. If there is speed guidance attached to this path, the H will offer a 
small detent in the speed lever for maintaining that speed. Since this new path is not a mission path, the 
H does not know where the pilot wants to turn, thus at every intersection with another guidance path, the 
H will highlight the possible intersections when the H-coa covers it and is within a certain distance. 

If the pilot wishes to turn onto a new heading, he can simply direct the velocity vector onto the desired 
heading using the heading rose as guidance. Normally the heading target is displayed as a waypole fixed 
at the desired heading and some fixed distance from the aircraft on the path displays in order to aid the 
pilot in pointing at it. Thus for heading guidance, the aircraft can be pointed at the waypole but it will 
never reach it because it is constantly moving with the aircraft. In this case, there are no tubes. The H 
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may recognize that it is heading towards the target and provide a slight ‘locking on’ feature that pulls the 
H and thus the haptic feedback, towards the target. The H will simply drive at the commanded velocity 
vector. If the pilot turns there is no resistance from the H. There are other salient cues that indicate that 
the pilot is not on a predetermined path. 

If the pilot wants to fly to a particular point in space, he simply aims the velocity vector at that point. 
Normally the target is presented on the Path displays in order to aid the pilot in pointing the H-coa at it. 
Like the heading change, there are no tubes. However, the H may recognize that it is heading towards the 
target (if it knows about the target) and provide a slight ‘locking on’ feature that pulls the H and thus the 
haptic feedback, towards the target. In other words, as the pilot moves the H-coa icon close to the target, 
the stick and vector will have a slight ‘gravitational’ pull towards the target. There are three types of 
inertial point targets that the pilot could aim at. The first, a waypole, is not technically a point, but 
represents a latitude/longitude. It is represented as a pole sticking out of the earth at that lat/long. A 
waypoint is simply a three dimensional point in space. A Crosspoint is a waypoint with a time restriction 
on it. 

If the velocity vector is directed at a waypoint or a waypole, the path display will present the time that the 
aircraft will arrive at that point. The pilot can vary speed accordingly using the speed lever. The pilot 
also has a speed indicator on the path display for making speed adjustments without consideration of any 
waypoints. This is method for commanding the velocity vector is called Point to Program. 

■ Point to Program is the use of force feedback, haptic inceptors to command the H (program the 
autopilot) to achieve a certain velocity vector. The Point to Program concept not only depends on the 
inceptors but also on the display providing the information needed to make domain specific inputs 
(e.g., cross waypoint X at time Y). 

■ A Wayplane is a reference of an altitude level. It has no latitude/longitude parameter. It is primarily 
displayed as a line in the profile view of the path display and it is not displayed in the plan view of the 
path display. A highlight/selected Wayplane may be displayed as a semi-transparent plan on the 
perspective view. The Wayplane acts as a path change guidance cue, the H will alert the pilot of the 
need to level off in the same manner as if the aircraft were coming up on any guidance change. 

■ A Waypole is an inertial reference of latitude/longitude position. It has no altitude parameter. It is 
displayed as a pole projecting from the ground into infinity. Additionally, it could be presented as a 
‘haptic’ magnet for the direction stick that lets the pilot know that the pole is an object that the H 
recognizes. The Waypole acts as a path guidance cue, the H will alert the pilot when the aircraft is 
approaching the Waypole in the same manner as if the aircraft were coming up on any guidance 
change. 

■ A Waypoint is an inertial reference to a latitude/longitude/altitude position. It is displayed as a 
regular geometric shape (e.g., sphere, star, cube, cross) on the display. Additionally, it could be 
presented as a ‘haptic’ magnet for the direction stick that lets the pilot know that the point is an object 
that the H recognizes. The Waypoint acts as a path guidance cue, the H will alert the pilot when the 
aircraft is approaching the Waypole in the same manner as if the aircraft were coming up on any 
guidance change. 

■ A Crosspoint is an inertial reference to a latitude/longitude/altitude position at a particular time. It is 
displayed as a regular geometric shape (e.g., sphere, star, cube, cross) that is different from the 
Waypoint shape on the display. Additionally, it could be presented as a ‘haptic’ magnet for the 
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direction stick and speed lever that lets the pilot know that the point is an object that the H recognizes. 
The Waypoint acts as a path guidance cue, the H will alert the pilot when the aircraft is approaching 
the Waypole in the same manner as if the aircraft were coming up on any guidance change. 

The ITP has transmitted its guidance information to the aircraft to be presented on the Path displays. In 
general, the H does not recognize any of this guidance beyond the next velocity vector change. More 
specifically, the H recognizes the current velocity vector that the pilot has captured, its termination point, 
and the new velocity vector that the guidance is presenting. The reason for having the H know about the 
next velocity vector is so that it can make cue the pilot to make an efficient turn. It is up to the pilot to 
translate the guidance into an H command. The purpose of having the pilot in this information flow chain 
is to keep the pilot involved and engaged in what the aircraft is doing and to allow the pilot to intervene if 
necessary. Thus the pilot is a critical part of this chain from guidance to activation. 

7.2. Sample Weather Scenarios 

7.2.1. Scenario Title: Wake turbulence from Large Aircraft on Runway 

The NFD aircraft is at the end of the taxiway having just been cleared to move onto and hold at the end of 
the runway. A large aircraft has just taken off. Through ADS-B-like information, the NFD aircraft 
knows the type of aircraft preceding it in the takeoff queue and the time the takeoff roll for the heavy 
began. Also available are wind speed and direction at ground level. As the NFD aircraft awaits takeoff 
clearance, the H system continuously evaluates the likelihood that the wake turbulence from the 
preceding aircraft is still a hazard and displays to the pilot a suggested hold time. The pilot has received 
clearance to move on to the runway. The H system informs the pilot, via a display, of the potential hazard 
from the wake turbulence and the estimated duration of the hazard. If the pilot tries to release the brakes 
while H system estimates a hazard, the H system resists brake release and gives an auditory warning to 
the pilot. The pilot can override the H system at any time by some prescribed action. The pilot should 
now be aware of the situation. 

7.2.2. Scenario Title: Icing in terminal area 

Aircraft is 10 minutes out from initial approach fix for a RNP approach into a 3000’ runway. It is 
descending from 5000’ to 3000’ by the IAF. Airspeed is cruise descent, 200kts. The H is leading the 
pilot through an approach and landing briefing. 

The aircraft is descending through a broken cloud layer; the outside air temperature is 23 degrees. Airport 
elevation is 0’ MSL and its reported conditions are an 800’ ceiling, 1 mile visibility, light and variable 
winds and an air temperature of 40 degrees. Another slower aircraft is 9 minutes out from the opposite 
IAF (standard T approaches). From weather datalink and real time sensing, the aircraft is aware of 
potential light icing and current aiiport conditions. 

No PIREPS of icing have been reported near the airport. The real-time icing sensor has just started to 
detect light ice accumulation. The system responds to the icing detection by — 

■ Issuing a caution to the pilot (haptic and visual signals), 

■ Increasing the approach speed by 1 5 knots above nominal, 

■ Restricting the low slow end of the speed envelope and use of flaps, and 
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■ Broadcasting an airplane generated “PIREP” for icing. 

The Actual system cautions that landing on 3000’ runway with icing restricted flight envelope does not 
provide normal safety margin, but predicts that the airplane is likely to reach freezing level at 2000’ and 
be ice free by landing. 

Airplane communicates the situation to the leading traffic and requests that it expedite its approach or 
delay — confirmation is received that traffic can expedite allowing approach to be flown at higher than 
normal speed while avoiding potential separation conflict. 

The icing sensor continues to measure rate of ice accumulation. The aircraft estimates performance 
effects of ice accumulation and likely margins. If performance appears nominal and icing sensor detects 
no icing, the Actual system requests that pilot make qualitative inspection for ice and report status. If 
pilot also reports no ice, icing restrictions are removed. The Notional system updates the diversion plan 
as needed to account for current situation. 

The aircraft reaches freezing level at 2100’ and recommends continued descent. A data li nk message is 
received from the preceding aircraft that it has landed and cleared the active runway. The airplane breaks 
out of the clouds at 900’ and the pilot signals to the aircraft that he has visual contact with the runway and 
intends to continue the approach to a landing. At 600’, the airplane uses cues to ask pilot if she confirms 
that the airframe is clear of ice. On receiving a clear signal from the pilot, the airplane reduces the 
approach speed only as needed to obtain nominal landing distance margins on the 3000’ runway. Just 
prior to 200’, both the airplane and pilot confirm that all is well for landing and the airplane transitions to 
landing behavior when appropriate. 


The airplane relaxes ice restriction only as needed to permit safe landing on a 3000’ strip. Both the 
airplane and the pilot confirm that all is well for landing and the airplane transitions to landing behavior 
as appropriate. 

7.2.3. Scenario Title: Weather change in Notional realm 

The aircraft is at cruise on a long flight. The route that the pilot has selected is based on comfort. The 
pilot is watching a movie. The pilot is engaged in the movie. A turn is approaching in 10 minutes. A 
storm cell is moving faster than predicted and will cross the flight plan, which will lead to strong 
turbulence. This crossing is about 45 minutes away. The aircraft has the current plan and pilot 
preferences. The aircraft does not know that the pilot is watching a movie. The aircraft calculates a 
decision point at which a decision must be made in order to give the storm cell a wide berth. The pilot 
has made the plan therefore a portion of that should reside in the pilot’s memory. The pilot knows the last 
turn that he made. The H will signal that a turn is approaching (exact time and/or distance TBD). As the 
aircraft comes upon the turn, it will freeze or lock out the Notional system from the pilot until the turn is 
made. It will then allow the Notional system to be activated. The Notional system will alert the pilot that 
there is a change in the weather. It will inform the pilot how this violates the current plan (primarily the 
preferences). It will give the pilot two options - 1) to go around the cell and 2) to reduce the comfort 
constraint. If the aircraft approaches the decision point, the attention-getting nature of the Notional 
system will rise up a notch or two. If the pilot does nothing, the last option is automatically selected. If 
the Notional system is interrupted by the Actual system, it stores the last inputs of the pilot. When the 
Notional system is reactivated. It has the option to ‘play through’ the last steps that the pilot took so as to 
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refresh the pilot regarding where he was and what he was doing. The pilot can continue on from there. 

If the Notional system sounds and the pilot ignores it (either consciously or unconsciously), the Notional 
system signals again. The pilot pauses the movie. He then directs his attention to the Notional system. 
He sees the problem and two alternatives that have been suggested by the Notional system. He does not 
like either one. He decides to try and go behind the cell and experience some turbulence but not as 
severe. He starts moving the route when the Actual turn signal calls his attention. He ignores it because 
he thinks he can finish the route changes in time. He tries to make the change, however the Notional 
system does not allow him to because it is illegal. The Notional system informs him about the illegality 
and offers another similar solution. While the pilot is reviewing it the Actual turn alert sounds and the 
Notional display fades, announces that an Actual interaction is required, and does not take any more 
commands. The pilot turns his attention back to the Actual system and makes the turn. After the turn is 
made, he returns to the Notional system, which replays his past moves and displays (including his attempt 
to do something illegal and the explanation). The pilot recalls the situation and the mind set and 
completes his inspection of the route. He accepts the changes and goes back to watching his movie. The 
rest of the flight continues normally. 

7.3. Sample Traffic Scenarios 

7.3.1. Scenario Title: Closure of destination 

The pilot and airplane have just started the approach, following a larger commercial airplane into a very 
busy airport. The airplane is under control - all systems working, fuel state is on plan and everything is 
progressing normally. The pilot is alert and in control. The weather is clear but a thunderstorm cell is 
rapidly approaching from the West. The alternate airport is now behind the aircraft to the south of the 
final destination. The airplane preceding the pilot’s aircraft has a mechanical failure and is stranded on 
the only active runway at the airport. 

ATC broadcasts that the airport is closed and the pilot and aircraft execute a missed approach. The H 
immediately upon identifying the need to perform a missed approach begins signaling the pilot through 
the stick, enhancing the image on the windscreen, and generating an audible alert. The enhanced view of 
the flight path may change to a different color or begin flashing. The normal behavior is for the H to 
follow the missed approach if the pilot does not indicate their desire to land. The situation is not critical 
yet so the H waits a short time for the pilot to evaluate the situation and get in the loop. The pilot should 
initiate the missed approach when directed by ATC. However, if the H senses the pilot is not responding 
or not executing the ATC requested procedure it may begin to follow the missed approach procedure. 
The Notional system has been listening to the ATC situation and became aware of the change in plans 
when the airplane was leveled off to fly the missed approach. It begins by getting an updated weather 
picture. The Notional system verifies that returning to the planned alternate is not a good idea because of 
the weather cell that moved in behind the airplane. It retrieves information about the alternates in the 
vicinity of destination and begins building and checking routes. Since fuel is low and many airplanes in 
the vicinity will be angling for the larger fields the Notional system determines a smaller field would be 
better. There is a small unattended airport north and slightly west of the destination that would allow the 
airplane to land safely. There is no ground transportation available however so the pilot would have to 
wait for a taxi to come out and pick him up. This alternate is marked as a possible. Other alternates are 
marked and the information is presented to the pilot. After the pilot selects the one he wants, the Notional 
system sends information off to ATC and the selected airport advising everyone of the pilot’s intentions 
to land at the newly selected airport. The Notional system begins feeding the flight legs to the H for 
guidance, once ATC has cleared them to proceed. 
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7.3.2. Scenario Title: Runway change at destination 


It is night and rainy, the aiiport is in the middle of the city in a plain terrain with some high-rise buildings 
nearby. The flight was smooth so far and the pilot has just started to plan for approach when the aircraft 
receives alerts from the ATC that the scheduled runway cannot be used. ATC requests the aircraft to land 
on another runway. There is not enough time to enter the information into the Notional system. And 
there is no need. The approach to the alternate runway is in the H guidance system (as are all approaches 
to all the runways). This approach is presented on the guidance display and the pilot simply turns off 
from his course and turns onto the new approach. Once on the new approach, the H signals that it can 
follow this approach and the pilot executes the appropriate landing behavior when it is time. The new 
approach continues as normal. 

7.4. Sample Aircraft Non/Rare-Normal Scenarios 

7.4.1. Scenario Title: Engine out in flight - twin-engine aircraft 

The aircraft is at cruise altitude. When the Actual system senses an engine failure, it immediately 
provides status information to the pilot. It then offers the guidance to the current abort alternate. This 
path is computed using the single engine capabilities of the aircraft and considers best runway geometry 
based on aircraft location, capability and wind strength and direction. 

The path is displayed on the Actual plan view display as well as the guidance display. The pilot can then 
follow that plan if he so chooses. To follow the plan, the pilot must turn the aircraft from its current 
course onto the alternate path. The pilot can also select other alternates that are displayed on the Actual 
plan display (only a limited set of viable options are displayed. Logic for limiting the set is the subject for 
further research) If the pilot selects another alternative, the H computes the best path to that airport. 

The Actual system informs the Notional system of the need to abort and the reason for doing so (i.e., 
engine failure). The Notional system determines if there are sufficient maintenance facilities. If so, it 
then goes on to determine alternate ways to complete the mission (car, other aircraft). If there are not 
appropriate facilities the Notional system locates appropriate airports that are within a reasonable (given 
engine loss and fuel status) range of the aircraft. If one exists, it informs the pilot of a better available 
alternate choice. The Notional system explains why this choice was presented. The pilot can add this 
new alternate to the current guidance and follow the guidance to that airport. 

Once the aircraft is safely on the ground, maintenance will be datalinked information concerning the 
engine failure. The H will compensate for missing thrust source and allow the pilot to taxi back to the 
hanger. 

7.4.2. Scenario Title: Engine out in flight - single-engine aircraft 

The aircraft is at cruise altitude. When the Actual system senses an engine failure, it immediately 
provides status information to the pilot. It then develops a plan for landing/ditching at the most suitable 
site given the aircraft’s glide characteristics and whatever information is in the database (e.g., extensive 
terrain maps). This path is computed using the control characteristics of the aircraft and considers best 
landing geometry based on aircraft capability and wind strength and direction. The pilot must then 
consult the plan and either accept or reject it. 

The path is displayed on the Actual plan view display as well as the guidance display. The pilot should 
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then follow that plan if he so chooses. To follow the plan, the pilot must turn the aircraft from its current 
course onto the alternate path. The pilot can also select other alternates that are displayed on the Actual 
plan display (only a limited set of viable options are displayed. Logic for limiting the set is TBD. If the 
pilot selects another alternative, the H computes the best path to that landing site. 

The Actual system broadcasts the declaration of emergency, cause of emergency, intentions, and the 
location of the aircraft. Once the aircraft is safely on the ground, rescue, maintenance, and ground 
transportation will be datalinked information concerning the engine failure. 

7.4.3. Scenario Title: Notional System failure in flight 

The Actual and Notional System each contain a mirrored database that contains terrain, airport, weather, 
and airspace information. The plan that is created by the Notional system (including alternates) is also 
contained in this shared database. 

If the Notional system fails, the pilot is notified by the Actual system. The guidance on the Actual system 
remains the same since it is the same as the Notional system was providing before it failed. 

The pilot is reminded that the Notional System will not be available to check for situational changes in the 
predicted future. The human will have to assume the back-up role for the Notional system. The Actual 
system modifies its behavior to complement the human in this new task in the following ways. 1) The 
pilot can use the Actual plan view display to ‘scroll’ ahead in the route. In other words, the Actual plan 
view display is no longer locked to the aircraft. 2) The Actual system will provide periodic (and 
appropriate) reminders to the pilot to check current conditions and compare with predicted conditions. 3) 
The Actual system (after sufficient and salient notification to the pilot) will follow the guidance even if 
the pilot has not command the aircraft to do so. 4) All standard/published airways will be visible in the 
Actual system to make it easier for the pilot to locate them and fly to them. (This encourages the pilot to 
either fly the planned route or to fly on published paths.) 

7.4.4. Scenario Title: H-mode system haptic cueing failure in flight 

The pilot has continuous ‘recurrent’ training on flying the aircraft because of the cooperative interaction 
between the H and the pilot using haptic feedback normally available through the stick. The pilot will 
develop expectations on what the H-would do based on experience. Should the cueing of the H fail; the 
pilot should have a mental model of what the H would have cued him because this is what has been 
encouraged during normal operations. Thus, the pilot should be able to make intelligent responses based 
on conditioned, skill-based behavior. The Actual system should also be forgiving of pilot errors in stick 
commands. 

7.5. Sample Human Non/Rare-Normal Scenarios 
7.5.1. Scenario Title: Pilot incapacitation 

The Actual system displays guidance to the pilot and signals the pilot when to perform the maneuvers. If 
the pilot fails to perform, the Actual system will make concerted efforts to engage the pilot’s attention. If 
the pilot is still not responding, the Actual system will announce a potentially incapacitated pilot and fly 
to the nearest airport (note that this is not necessarily the alternate that pilot may have selected). It will 
not take facility or transportation considerations into account. This would simply be the fastest way 
down. The H will perform the landing on its own, unless the pilot tries to intervene. If the pilot 
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intervenes, the H will return to its normal operations. 

8. Summary and Discussion 

8.1. NFD Summary 

The goal of this program has been to make operating an aircraft easier and more intuitive while also 
making it safer. Either goal is ambitious, but we believe that the approach we have taken and the 
concepts that we have designed will not only achieve both of these goals but will do them elegantly. 
Perhaps the central tenet of this approach has been to consider the entire flight experience in the design 
process rather than just an isolated element. The NFD concept accounts for performing the flight, 
planning for the flight, dealing with unexpected occurrences, rehearsing for the flight, and reviewing the 
flight. The application of design metaphors to each of these functions has enabled us to develop what we 
consider to be a consistent, comprehensive, and cohesive design that is expandable as to accommodate 
new technologies as they mature. 

The design strives to engage the human in the operation of the vehicle in such a way that the human is not 
overwhelmed with either mental or physical workload yet feels meaningfully involved in the flight. The 
design assumes that one of the human’s more important roles in the flight deck is looking at the big 
picture and dealing with unexpected or unanticipated occurrences. Therefore, the human is called upon to 
make high-level changes in the flight in order to keep him in the loop, while the automation handles the 
inner loop control and monitoring (which would tax the human if it were assigned to him). 

The automation in the NFD is used to collect and store knowledge of the domain (e.g., simulation of the 
vehicle, airspace rules and regulations, weather information), to monitor the mission, the environment, the 
vehicle and the pilot, to alert the pilot to tasks and conditions, and to perform precision, deterministic, and 
repetitive tasks. The vehicle possesses horse-like intelligence but not human-like intelligence. This 
allows the pilot to have a natural interaction with the vehicle without expecting it to ‘think’ for the 
human. 

8.2. Human Centered vs. Technology Centered 

Perhaps the most common criticism of this design approach is that it does not utilize the full potential of 
automation. Many feel that a more fully automated vehicle would be more satisfactory approach. Rather 
than having the human to be involved with the control of the vehicle at all, the human could enter a 
mission goal and the machine would perform the goal - much like a chauffer. They argue that current 
airline transports have flight management systems that allow the pilot to program the route and then 
watch the airplane fly the route. The problem with these approaches is that they do not account for the 
unexpected or unanticipated. And yet aircraft carrying humans have to deal with the two most 
unpredictable phenomena - human beings (involved in the design, manufacture, and operation) and 
weather. Massive amounts of research and computational modeling and computing power have been 
pressed into the service of predicting weather and yet, while good, they are nowhere near 90% correct. 
This is not acceptable. The human complemented by the machine can perform much more effectively 
and can implement common sense solutions to problems that machines cannot. However, in order to do 
so, they must be aware of what is going on. While it is possible for them to be passively aware, this 
becomes more difficult as reliability increases - humans become bored and complacent. Involving them 
in meaningful ways without overloading them should keep them aware of the situation so that if an 
unexpected event occurs they will not be caught unawares. 
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In short, we believe that the Naturalistic Flight Deck concept approaches an optimal use of technology in 
human-machine systems. Of course, much research and development remains in order to evaluate this 
claim. However, the combined benefits of ease of use and increased safety make it a worthwhile task. 
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